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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
