registry team mailing list archive

[Christian Kastner <27520@xxxxxxxxxxxxxxxxxx>]

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 Registry
Administrators, which is the registrant for Debian.