Hi!
>X-Original-To: [email protected]
>From: Andy Lutomirski <[email protected]>
>To: Andries Brouwer <[email protected]>
>Cc: [email protected]
>Subject: Re: the umount() saga for regular linux desktop users
>
>Andries Brouwer wrote:
>>On Fri, Dec 31, 2004 at 05:41:02PM +0000, William wrote:
>>
>>
>>>Regularly, when attempting to umount() a filesystem I receive
>>>'device is busy' errors. The only way (that I have found) to solve
>>>these problems is to go on a journey into processland and kill all
>>>the guilty ones that have tied themselves to the filesystem
>>>concerned.
>>
>>
>>Do you know about the existence of the MNT_DETACH flag of umount(2),
>>or the -l option of umount(8)?
>>
>>It seems that does at least some of the things you are asking for.
Well, umount -l can be handy, but it does not allow you to get your CD
back from the drive.
umount --kill that kills whoever is responsible for filesystem being
busy would solve part of the problem (that can be done in userspace,
today).
Of course, even nicer would be "filesystem goes away now, all
operations fail", but that needs kernel support.
>Sometimes I want to "unmount cleanly, damnit, and I don't care if
>applications that are currently accessing it lose data." Windows can
>do this, and it's _useful_.
Agreed. When some machine refuses to eject cd because it is
busy... That's bad. I have strong temptation to just remove AC power,
plug it back and then claim my CD...
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
On Sun, Jan 02, 2005 at 08:37:24PM +0100, Pavel Machek wrote:
> Well, umount -l can be handy, but it does not allow you to get your CD
> back from the drive.
>
> umount --kill that kills whoever is responsible for filesystem being
> busy would solve part of the problem (that can be done in userspace,
> today).
>...
What's wrong with
fuser -k /mnt && umount /mnt
?
> Pavel
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Hi!
> > Well, umount -l can be handy, but it does not allow you to get your CD
> > back from the drive.
> >
> > umount --kill that kills whoever is responsible for filesystem being
> > busy would solve part of the problem (that can be done in userspace,
> > today).
> >...
>
> What's wrong with
>
> fuser -k /mnt && umount /mnt
Okay, probably nothing (I knew about fuser, but did not know about -k
option...). fuser followed by ps and kill is not nice.
[Perhaps umount could tell user about fuser -k ?]
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
Am Sonntag, 2. Januar 2005 21:11 schrieb Adrian Bunk:
> On Sun, Jan 02, 2005 at 08:37:24PM +0100, Pavel Machek wrote:
>
> > Well, umount -l can be handy, but it does not allow you to get your CD
> > back from the drive.
> >
> > umount --kill that kills whoever is responsible for filesystem being
> > busy would solve part of the problem (that can be done in userspace,
> > today).
> >...
>
> What's wrong with
>
> fuser -k /mnt && umount /mnt
1. Would need suid.
2. Is a mindless slaughter of important processes.
3. Is a race condition.
Regards
Oliver
On Sun, Jan 02, 2005 at 09:11:47PM +0100, Adrian Bunk wrote:
> On Sun, Jan 02, 2005 at 08:37:24PM +0100, Pavel Machek wrote:
>
> > Well, umount -l can be handy, but it does not allow you to get your CD
> > back from the drive.
> >
> > umount --kill that kills whoever is responsible for filesystem being
> > busy would solve part of the problem (that can be done in userspace,
> > today).
> >...
>
> What's wrong with
>
> fuser -k /mnt && umount /mnt
>...
I meant
fuser -km /mnt && umount /mnt
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Adrian Bunk <[email protected]> writes:
> What's wrong with
>
> fuser -k /mnt && umount /mnt
Better: fuser -km /mnt
Andreas.
--
Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
On Sun, Jan 02, 2005 at 09:34:16PM +0100, Oliver Neukum wrote:
> Am Sonntag, 2. Januar 2005 21:11 schrieb Adrian Bunk:
> > On Sun, Jan 02, 2005 at 08:37:24PM +0100, Pavel Machek wrote:
> >
> > > Well, umount -l can be handy, but it does not allow you to get your CD
> > > back from the drive.
> > >
> > > umount --kill that kills whoever is responsible for filesystem being
> > > busy would solve part of the problem (that can be done in userspace,
> > > today).
> > >...
> >
> > What's wrong with
> >
> > fuser -k /mnt && umount /mnt
>
> 1. Would need suid.
It needs suid only if you aren't root and you want to kill processes you
don't own.
Yes, this might cause problems e.g. if users are allowed to mount their
cdroms, but simply allowing them to kill processes of other users who
access this device isn't a solution, too.
> 2. Is a mindless slaughter of important processes.
It's what Pavel wanted to get included in umount.
Usually, you'll let fuser give you the list of processes and inspect
them manually.
> 3. Is a race condition.
Then put it into a while loop that executes until umount returns 0.
I still fail to see why I should implement half of fuser in umount.
Either you are working at the command line and know about fuser or you
are working through a GUI which can offer you a "kill all applications
accessing this device" button that calls fuser.
> Regards
> Oliver
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Hi!
> > > > Well, umount -l can be handy, but it does not allow you to get your CD
> > > > back from the drive.
> > > >
> > > > umount --kill that kills whoever is responsible for filesystem being
> > > > busy would solve part of the problem (that can be done in userspace,
> > > > today).
> > > >...
> > >
> > > What's wrong with
> > >
> > > fuser -k /mnt && umount /mnt
> >
> > 1. Would need suid.
>
> It needs suid only if you aren't root and you want to kill processes you
> don't own.
>
> Yes, this might cause problems e.g. if users are allowed to mount their
> cdroms, but simply allowing them to kill processes of other users who
> access this device isn't a solution, too.
>
> > 2. Is a mindless slaughter of important processes.
>
> It's what Pavel wanted to get included in umount.
>
> Usually, you'll let fuser give you the list of processes and inspect
> them manually.
>
> > 3. Is a race condition.
>
> Then put it into a while loop that executes until umount returns 0.
>
> I still fail to see why I should implement half of fuser in umount.
> Either you are working at the command line and know about fuser or you
> are working through a GUI which can offer you a "kill all applications
> accessing this device" button that calls fuser.
Okay, so the right solution is probably something more like
while umount /mnt; do
fuser -km -TERM /mnt
sleep 1
fuser -km /mnt
done
Not sure how many command line users can do this... Perhaps including
fumount script doing this is good idea?
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
On Sun, Jan 02, 2005 at 09:56:50PM +0100, Pavel Machek wrote:
>
> Okay, so the right solution is probably something more like
>
> while umount /mnt; do
> fuser -km -TERM /mnt
> sleep 1
> fuser -km /mnt
> done
>
> Not sure how many command line users can do this... Perhaps including
> fumount script doing this is good idea?
A command line user only needs to know about fuser, and in the unlikely
case if the race condition Oliver thought of occurs he'll note since
umount will give an error message.
I'd even say the more common case is to use fuser to get the PIDs of the
processes and manually check which they are - e.g. you might not want to
kill your OpenOffice with many open documents only because you'd
forgotten that it still has one document open on the file system you are
trying to remove.
> Pavel
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Adrian Bunk wrote:
>On Sun, Jan 02, 2005 at 09:11:47PM +0100, Adrian Bunk wrote:
>
>
>>On Sun, Jan 02, 2005 at 08:37:24PM +0100, Pavel Machek wrote:
>>
>>
>>
>>>Well, umount -l can be handy, but it does not allow you to get your CD
>>>back from the drive.
>>>
>>>umount --kill that kills whoever is responsible for filesystem being
>>>busy would solve part of the problem (that can be done in userspace,
>>>today).
>>>...
>>>
>>>
>>What's wrong with
>>
>> fuser -k /mnt && umount /mnt
>>...
>>
>>
>
>I meant
>
> fuser -km /mnt && umount /mnt
>
>cu
>Adrian
>
>
>
I'm as newbie as they get but the above command just made my system
freeze hard and I could do nothing but reboot (use the power switch). I
had nothing mounted there but have a directory
under /mnt where I occasionaly mount my samba share. (which was not
mounted when I tried this) . So much for user friendlyness ... oh well ...
~puneet
On Sun, Jan 02, 2005 at 10:05:36PM +0100, Adrian Bunk wrote:
> On Sun, Jan 02, 2005 at 09:56:50PM +0100, Pavel Machek wrote:
> >
> > Okay, so the right solution is probably something more like
> >
> > while umount /mnt; do
> > fuser -km -TERM /mnt
> > sleep 1
> > fuser -km /mnt
> > done
>
> A command line user only needs to know about fuser, and in the unlikely
> case if the race condition Oliver thought of occurs he'll note since
> umount will give an error message.
There's a much more interesting race: another process succesfully umounting
the thing while this one's asleep.
--
Frank
Frank van Maarseveen schrieb:
> On Sun, Jan 02, 2005 at 10:05:36PM +0100, Adrian Bunk wrote:
> > On Sun, Jan 02, 2005 at 09:56:50PM +0100, Pavel Machek wrote:
> > > Okay, so the right solution is probably something more like
> > >
> > > while umount /mnt; do
> > > fuser -km -TERM /mnt
> > > sleep 1
> > > fuser -km /mnt
> > > done
> There's a much more interesting race: another process succesfully umounting
> the thing while this one's asleep.
For those who don't know what happens: fuser -km /mnt will act like
fuser -km / in that race and kill all processes.
BTDT :-(