Linked by Amjith Ramanujam on Wed 23rd Jul 2008 16:34 UTC, submitted by LinucksGirl
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.
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: fuser and screen collab
by Kokopelli on Thu 24th Jul 2008 00:11
in reply to "RE: fuser and screen collab"
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
RE[3]: fuser and screen collab
by jhoo on Thu 24th Jul 2008 15:12
in reply to "RE[2]: fuser and screen collab"
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.
RE[2]: fuser and screen collab
by Bending Unit on Thu 24th Jul 2008 10:48
in reply to "RE: fuser and screen collab"
Member since:2005-07-06
RE[3]: fuser and screen collab
by B. Janssen on Thu 24th Jul 2008 12:43
in reply to "RE[2]: fuser and screen collab"
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?
Recent Original Stories
Recent Comments
Headlines
Random Comments
Random Stories
Random OS Link
Member since:
2006-10-08
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... :-)