Linked by Amjith Ramanujam on Wed 23rd Jul 2008 16:34 UTC, submitted by LinucksGirl
Linux In this article, learn how to be a more productive Linux systems administrator. These 10 essential tricks will lead you on your way to being one powerful Linux systems administrator. Learn about SSH tunnels, VNC, password recovery, console spying, and more. Examples accompany each trick, so you can duplicate them on your own systems.
Thread beginning with comment 324256
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: fuser and screen collab
by Doc Pain on Wed 23rd Jul 2008 21:48 UTC in reply to "fuser and screen collab"
Doc Pain
Member since:
2006-10-08

Liked the tips about 'fuser -k' [...]


Regarding the trick "Unmounting the unresponsive DVD drive" I would suggest the -f flag to umount, and maybe the use of tools like camcontrol or atacontrol. I know the article is about Linux, but maybe there are similar tools.

# umount -f /media/dvd

would force the unmount of the media. If this is not sufficient, tools like camcontrol or atacontrol could be used to reset or reinitialize the ATAPI components (the drive or the whole bus) in order to clear any persisting drive locks.

Just an idea... :-)

Reply Parent Score: 1

RE[2]: fuser and screen collab
by Kokopelli on Thu 24th Jul 2008 00:11 in reply to "RE: fuser and screen collab"
Kokopelli Member since:
2005-07-06

I usually prefer doing a "lsof |grep [mount point]" to give me an idea of who or what is using it. fuser does not do as good a job in my experience, which is admittedly me trying fuser after reading the article.

Taking as an example playing a movie file from a mounted USB hard drive. fuser /dev/sdd1 or /dev/sdd or /media/disk will generate no output. It will only generate list the culprit if you do do "fuser [file that is open]".

You can force unmount but I find 99% of the time you can cleanly do so once you figure out what is preventing the umount.

NOTE: "lsof +D [mount point]" does the same thing, piping to grep is habit

Edited 2008-07-24 00:30 UTC

Reply Parent Score: 2

RE[3]: fuser and screen collab
by jhoo on Thu 24th Jul 2008 15:12 in reply to "RE[2]: fuser and screen collab"
jhoo Member since:
2006-03-24

NOTE: "lsof +D [mount point]" does the same thing, piping to grep is habit


Just to be a pedant, it doesn't do the same thing, it does something markedly different, however it does often produce the same result.

Actually the results can be very different, take for example the case of "lsof +D /bin/" which will find any open files under /bin and "lsof |grep /bin/" which will find any files with /bin/ in their path e.g. files in /usr/bin as well as files in in /bin.

Reply Parent Score: 1

Bending Unit Member since:
2005-07-06

A desktop operating system should not lock the drive in the first place. I have never liked that thing about unix-like systems. Removable devices have always been error prone on my Linux systems.

Reply Parent Score: 2

B. Janssen Member since:
2006-10-11

A desktop operating system should not lock the drive in the first place. I have never liked that thing about unix-like systems. Removable devices have always been error prone on my Linux systems.


Phew, lucky us that TFA explicitly mentions enterprise level GNU/Linux servers.

Regardless of desktop or server, it is just bad policy to eject a removable media while somebody/thing is accessing it. Really. Remember the pain older MS Windows releases would put you through by reliably crashing if you'd tried something like that?

Reply Parent Score: 3