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.

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
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs

Reply via email to