On Fri, 2013-03-08 at 16:05 +0100, Erwan LOAEC wrote: > Hello autofs team, > > I use autofs in an heavy production environment with a perpetual flow. > The problem I have is if I add a new cifs share for a given remote > server, this new share never appear under the autofs if the flow is not > stopped. That's right, multi-mount map entries must completely expire to get updated. The main problem with updating active multi-mount map entries is it is far to easy to completely break automount when trying to umount stale mount triggers and adding new mount triggers, not the least of which is the possible incompatible changes to hierarchic dependence within the multi-mount mount tree. > > Is there a way to schedule a periodic refresh the share list ? Nope. > > For now I use autofs 5.0.6 (with about 50 patchs: the last one is > autofs-5.0.6-fix-configure-string-length-tests.patch). I've look into > the next version/patch, I didn't see anything related to my problem... > OS version: Debian squeeze (kernel 2.6.32) There is a fairly recent patch series that attempts to allow the internal hosts map to update host exports when a HUP signal is received. That method could be extended (which I intended to do at some stage) to cater for updating multi-mount map entries on receiving HUP signal. The incompatible hierarchic dependence issue is still the main concern. Extending this to program maps, like the example program map auto.smb, is not so simple because there is currently no way for a program map to enumerate itself, so the map can't be updated with a HUP signal. IOW there's no read map function defined in the autofs program map module. More than that autofs can't know how to get an updated entry other than calling the program map lookup module mount function which currently will also, unconditionally, attempt to mount the entry. So it isn't a straight forward problem to solve either. Ian -- To unsubscribe from this list: send the line "unsubscribe autofs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
