On 09/02/2010 05:09 PM, Stephane Chazelas wrote: >> This appears to be a variant of Debian bug #512757 against cron. Can >> somebody confirm this for me? > [...] > > Pretty much, though for me reordering the init scripts wasn't enough as > there was some delay between the time nslcd (the LDAP cache daemon) was > started and it being operational.
I'm just guessing here, but this may be a bug in the nslcd init script, see the following discussion on debian-devel@: http://lists.debian.org/debian-devel/2010/05/msg00130.html ie, services not yet being fully operational when their init script terminates. > Or because it checks before executing the jobs anyway, cron could skip the > check for orphan crontabs at startup altogether (or maybe just issue a > warning that some crontabs could be cleaned up). Once cron considers a crontab "broken", it is ignored until it is modified again (checked by mtime). One way this could be solved is similar to the solution in Debian bug #433609. The fix there was to keep re-checking a dangling symlink until it was fixed, even though the symlink's mtime never changed. In that case, however, it was clearly cron's fault. Here, cron just calls getpwnam(); I hesitate to add such a "fix" when the underlying cause does not lie with cron. What I will do is add nslcd to Required-Start in Debian cron's LSB init headers (which would be sync'ed back to Ubuntu eventually), but for any further changes I'd like to see all other possibilites ruled out (ie, nslcd-signalling-ready-but-not-yet-operational). Regards, Christian -- cron no longer respects nsswitch.conf https://bugs.launchpad.net/bugs/27520 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
