Re: Final fix for Autofs issues
Hi
On Mon, Feb 13, 2012 at 08:13:49PM +0100, Petter Reinholdtsen wrote:
>
> [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?
>
Well, OS > Squeeze means Wheezy and derived OS (actually Ubuntu uses
upstart, but the problem is not solved, even out of SysV-init)
> > 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.
>
Not impossible, indeed. Would be amazing to have a persistent cache (from boot
to boot) or having a starting mount table as a file, to be refreshed by LDAP;
kind of autofs5-ldap-sss :)
The strange fact is that watching in log, the error output is
that the LDAP server is not found. On my Edu - Squeeze this could be explained
with a resource hog (nobody has reported this out of me on qemu with my
dual core only). But on wheezy I think that the boot order is somehow wrong,
because the failing is systematic, not just occasional like in virtualized
squeeze.
> > 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.
No idea. I may have time wednesday to dig into this and also to
clean up educlient.deb sources.
I think, that is probably not mandatory to put an autofs restart on rc2,
like a winning team do not need to be reorganized.
But we have to keep in mind this kind of problem; it will pop up again
and again in the future.
Best regards
Giorgio
--
Giorgio Pioda - Sysadmin SPSE-Tenero
Cell +41 79 629 20 63
Uff. +41 91 735 62 48
Reply to: