Thus spoke H. Peter Anvin on 22-Feb-99 :
>> >
>> > Basically, in autofs v3 there is no way of taking control over an
>> > abandoned automount, and I haven't been planning on that kind of
>> > support for autofs v4 either; it is really hard to do and I see very
>> > little benefit to it.
>>
>> I disagree that this feature has "little benefit". Imagine, you want
>> to move a user from one partition to another. That happens sometimes
>> if you are a sysadmin. Changing NIS maps will not solve the problem.
>> Yep, then you end up rebooting the machines or tell the user, he/she
>> can only log onto machines, which have been not used by him/her.
>>
>> Or is there another simple official procedure, how to deal with
>> these situations and avoid reboot?
>
> Yes, you explicitly umount *that directory*.
Maybe I do not understand what you mean with
"explicitly umount *that directory*"
umount /home/user1
on a autofs mountpoint /home does not work. Therefore the directory entry
/home/user1 is stuck.
Back to amd. Amd provides just a dynamical link layer over a mount point /home.
The real process sees /net/host/userspace/user1.( Remember, we had the
discussion about getcwd()). Therefore you can destroy the layer, by killing an
restarting the automounter, without affecting the processes.
> Note you can't have
> processes holding the filesystem busy, no matter what you do. It just
> *cannot* work.
It looks to me, that the reason is part of autofs, the autofs filesystem, runs
in the Linux kernel. Bad luck.
>> years and the AMD linux mount code is not maintained any more.
>
> It is, under the name am-utils, as far as I know.
Thanks for the hint.
Frithjof
"If you see someone without a smile, give him one of yours"
Frithjof Anders
Institut fuer Festkoerperphysik
Technische Universitaet Darmstadt
Hochschulstr. 6
64289 Darmstadt, GERMANY
Tel +49 (6151) 16-5235 email: [EMAIL PROTECTED]
FAX +49 (6151) 16-3681
