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