Less known Solaris Features: fuser

You know the problem. You try to unmount a filesystem, but all you get is a “Device Busy”. How do you find the process blocking the unmount?

fuser

fusers enables you to look for the processes that access a directory or a file. For example we can check for all processes using the / filesystem as their “working filesystem”:

# fuser -c /<br />
/:      701ctm     676ctm     675ctom     672ctom     596ctm     592ctm     585ctm     584ctom     581ctom     568ctm     523ctom     521ctom     481ctom     478ctom     477ctom     469ctom     456ctom     437ctom     425ctm     418ctom     412ctom     402ctom     401ctom     399ctom     380ctom     379ctom     366ctm     345ctom     341ctom     338ctom     333ctom     332ctom     319ctom     272ctom     262ctom     153ctm     140ctm     133ctom     131ctom     125ctm     100ctom      18ctm       9ctom       7ctom       1ctm

I´m sure you alread assume, that the numbers stand for the process id´s. But what does all that letters mean. I will cite the manpage for this:

• c: Indicates that the process is using the file as its current directory.
• m: Indicates that the process is using a file mapped with mmap(2).
• n: Indicates that the process is holding a non-blocking mandatory lock on the file.
• o: Indicates that the process is using the file as an open file.
• r: Indicates that the process is using the file as its root directory.
• t: Indicates that the process is using the file as its text file.
• y: Indicates that the process is using the file as its controlling terminal.
</ul>

But fuser can do more for you

Okay, now you know which processes uses a filesystem. But let´s assume you have to unmount a filesystem for maintaining the storage. But there are still some users, who didn´t read their mails and you can´t unmount it.


<br />
# cd /mnt/application<br />
# sleep 1000&<br />
[1] 691<br />
# sleep 1000&<br />
[2] 692<br />
# cd /<br />
# umount /mnt/application<br />
umount: /mnt/application busy

Dammit ... Okay, let´s check for the offending processes:


fuser -u /mnt/application<br />
/mnt/application:      692c(root)     691c(root)

And now comes the kicker: fuser can kill all processes using a certain file or directory. You warned your users ...


# fuser -k -u /mnt/application<br />
/mnt/application:      692c(root)     691c(root)<br />
[2]+  Killed                  sleep 1000  (wd: /mnt/application)<br />
(wd now: /)<br />
[1]+  Killed                  sleep 1000  (wd: /mnt/application)<br />
(wd now: /)<br />
# 

Now we can unmount the directory:


# umount /mnt/application<br />
#

A neat trick with fuser

Okay, working with PID may a little bit cumbersome. Pete Shanahan posted a neat trick a long time ago. Let´s assume the example with the both sleep processes. You´ve remounted the filesystem an started some programs while beeing in the /mnt/application filesytem:


# cd /mnt/application<br />
# sleep 1000&<br />
[1] 726<br />
# sleep 1000&<br />
[2] 727<br />
# cd /<br />
# ps -o pid,args -p "$(fuser /mnt/application 2>/dev/null)"<br />
  PID COMMAND<br />
  726 sleep 1000<br />
  727 sleep 1000<br />
#

Do you want to learn more ?

docs.sun.com: fuser(1M)
Pete Shanahan´s fuser trick</a