> >>
> >> I imagine the official line on this is that you don't need to restart
> >> an automount process because you can just change the map file and it
> >> should take effect immediately. The "autofs reload|restart" only kills
> >> or starts mounts which have changed in the auto.master file.
> >>
> >> I guess I'll either have to kill those processes or permanently mount
> >> the directories until the next reboot!
> >>
> >
> > 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*. Note you can't have
processes holding the filesystem busy, no matter what you do. It just
*cannot* work.
> That is IMOP the major drawback of autofs versus good old AMD, we
> did use before. AMD could be restarted with no problems. The only
> reason, we switch to autofs was, that LINUX mount changed over the
> years and the AMD linux mount code is not maintained any more.
It is, under the name am-utils, as far as I know.
-hpa
