Re: Final fix for Autofs issues

[Petter Reinholdtsen <pere@hungry.com>]

[Giorgio Pioda]
> on OS > than Squeeze autofs starts too early on boot, and in the
> autofs logs (in debug mode) the LDAP not responding is clearly
> visible. I've filled a bug in BTS yesterday for autofs5-ldap. The hack
> of restarting it with a script placed in if-up.d works.

Not quite sure what you mean with "on OS > than Squeeze".  With Squeeze,
the init.d script dependency for autofs seem to be solid, as autofs
depend on nslcd which depend on slapd, causing autofs to always start
after slapd is operational.  Is this not the case for other versions?

> I've tried many other solutions, like putting "sleep 10" at
> /etc/init.d/autofs or in /etc/init/autofs (for upstart), or triing to
> slow down the graphical startup (thinking that a resource hog in the
> virtualized system could be the reason of the problems), or even
> modifiing the LDAP_TIMEOUT and LDAP_NETWORK_TIMEOUT options in
> /etc/default/autofs.
>
> But none of these solutions are better than a restart after the setup
> of the network interface.  Even the complete removal of n-m is not
> very effective.

Could the fact that restart improve the situation be caused by autofs
caching mount failures?  I believe a restart flushes this cache and make
it try again.

> IMHO if the restart occours with a logged user, this will NOT break
> the nfs connection. I've never seen this, even calling the restart
> manually inside an Edu workstation, and being graphically logged with
> the first exported user. Probably, once established the NFS connection
> is somehow indipendent from autofs.

Good to hear that existing NFS mounts stay up, but will they be
automatically unmounted when they are no longer used?  Do not want to
end up with a lot of lingering and unused NFS mounts.
-- 
Happy hacking
Petter Reinholdtsen