Hi Ian Thanks for this :)
At the behest of one of the data admins, I scheduled a '/sbin/service autofs reload' at 8AM, 12PM, 3PM and 6PM. In addition to this, there is a nightly autofs reload. The day after putting in the addition reloads, most of our EL3 boxes had stale mounts. Stopping the autofs reloads during the day stopped the stale mounts occuring. Do you have any recommendations for scheduling regular autofs updates? Something like DNS style serial numbers would be nice to be able to query the clients to make sure their maps are up to date. Yep, I realise this is next to impossible to implement and maintain compatibility with the rest of the world... CC -----Original Message----- From: Ian Kent [mailto:[EMAIL PROTECTED] Sent: Wednesday, 2 January 2008 9:51 AM To: Coe, Colin C. (Unix Engineer) Cc: [email protected] Subject: Re: [autofs] How does autofs know when the maps have changed? On Wed, 2008-01-02 at 07:12 +0900, Coe, Colin C. (Unix Engineer) wrote: > Hi all > > We have a mix of Linux and Solaris workstations and servers. In Solaris > land, an 'automount -v' is run nightly to pickup any changes to the > automount maps. Is this required with the autofs distributed by RedHat? > Does autofs do any checking to see if the map has changed? We're running > RedHat EL 3, 4 and 5, (mostly) fully patched. Basically, yes and no! There are some differences between version 4 and version 5 but below is generally the case. For indirect maps it should see changes but a HUP signal can be used to force an update. For direct maps you need to send a HUP signal to the daemon. A "service autofs reload" will do this. But be aware that RHEL 5.1 has a bug that can cause it to wipe out the map under some circumstances. Ian NOTICE: This email and any attachments are confidential. They may contain legally privileged information or copyright material. You must not read, copy, use or disclose them without authorisation. If you are not an intended recipient, please contact us at once by return email and then delete both messages and all attachments. _______________________________________________ autofs mailing list [email protected] http://linux.kernel.org/mailman/listinfo/autofs
