Jeff Moyer wrote:
>>
>> I can look at the contents of /proc/mounts and here I see the autofs
>> tree, which is kept. So I do not understand your remark
>> saying it is consulted every single lookup. Does the option -browse
>> mather here? I'm using that and because this forces the automounter to
>> remember the data right?
>>     
>
> OK, I was wrong.  Sorry about that (I was confused with the fact that
> program maps don't support the -browse option, since they can't support
> map enumeration).  I admit I am not up to speed on v5.  However, it
> looks to me like a HUP signal will not cause the service thread for your
> mount point to restart unless the actual program map changed.  This
> means the cache will still be in tact, as you observed.  I suspect we
> should probably clear the cache for any maptype that does not support
> enumeration upon receiving a HUP signal.  Ian, what do you think?
>
> Cheers,
> Jeff
Ok,

question: how does the automounter determine that the acual program map 
has changed?

Futher, it may be a good thing to develop an utility which manages 
mountpoints and related maps.
(like autofsctl)

One of the things is to make executable maps run again and let the 
automounter read the data.
Reloading the configuration is another task.

Stef


_______________________________________________
autofs mailing list
autofs@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/autofs

Reply via email to