Stef Bon wrote: > Ian Kent wrote: >> Stef Bon wrote: >> >>> Ian Kent wrote: >>> >>>> On Wed, 2009-04-08 at 18:14 +0200, Stef Bon wrote: >>>> >>>> >>>>> Hello, >>>>> >>>>> I've been working on a construction which adds an autofs managed >>>>> mountpoint to the homedirectory, when: >>>>> a. an usb device or more than one is detected when logging in >>>>> b. an usb device is plugged in during a session >>>>> >>>> What version of autofs did you say you are using? >>>> >>> Well, 5.0.4. >>> >> >> OK, then the daemon should remain running as long as there is at least >> one entry in the master map. If the daemon receives a HUP signal then >> any mount handling threads that terminate will send SIGTERM to the >> signal catching thread. If the master map becomes empty during this >> SIGTERM check autofs will exit. That is what the daemon exit condition >> is and we do need such a condition to be able to exit at all. >> >> If something else is happening in your case then we need to work out >> what's going on. >> > > Yes, the auto.master file is not empty. In all of my cases, and in the > example below, the auto.master file has one line which is there always: > > /mnt/sd /etc/autofs/auto.sd --timeout=50 > > > I remember that I have added this line to prevent this unwanted > behaviour. In my construction it can happen that when no users are > logged in (after logout), there are no mountpoints, and then the > automounter did stop also. So then I added this line, and the behaviour > disappeared. Now it's back again. Removing a mountpoint, and reloading > gives this behaviour, even if there are other mountpoints and maps in > the auto.master file. > > Ok, so this should be a bug, if you say that, when the auto.master file > is empty, the automounter should stop after a HUP signal. > Apart from this bug, I do not understand this. You say it's necessary to > exit at all, but is this a technical reason? The master daemon should > not stop after a reload signal, even if the master file is empty.
OK, looks like a bug. I'll look further, using your example. What I'm saying is that, in order to exit there must be such a condition and that it isn't as straight forward as just saying the daemon shouldn't exit after receiving a HUP signal even if the master map is empty. The issue of continuing to run or not has come up a number of times and it is tricky. At the very least an empty master map is likely to continue to be the exit condition. > > Stef Bon >> However, there are a couple of patches against 5.0.4 in this area of the >> code, but I'm not sure they make the above behaviour different. We could >> give then a try. >> >> >>> I can imagine that my story is complicated, so I've found a simple way >>> to get the same behaviour. >>> >>> Add the following line to the auto.master file in /etc/autofs: >>> >>> /mnt/smb /etc/autofs/auto.smb >>> >>> Start the daemon, or, if already running, do a reload. >>> >>> Play with the new mountpoint, so do something like : >>> >>> ls /mnt/smb/<valid name of smb host> >>> >>> look at the result, a tree should be the result. >>> >>> Now remove the line again, (thus: "/mnt/smb /etc/a...."), and give the >>> daemon a reload again, >>> >>> and the daemon stops. >>> >> >> As it should if there are no master map entries remaining. >> I've been here before and I think trying to change the exit condition >> will be quite hard. >> >> >>> I've got a 2.6.27.9 kernel, patched with >>> >>> autofs4-2.6.27-dev-ioctl-20081029.patch and >>> autofs4-2.6.27-v5-update-20081027.patch >>> >>> Stef Bon >>> >>> >> >> > _______________________________________________ autofs mailing list [email protected] http://linux.kernel.org/mailman/listinfo/autofs
