Package: cron Version: 3.0pl1-118 Severity: normal This issue has been discussed at length in LP #27520 [0]; this bug report intends to condense the relevant information from that report.
Since the cron daemon now recovers from various filesystem- and syntax-related errors, one could argue that it should also recover from the one remaining error that is currently fatal: an unsuccessful getpwnam() call when parsing crontabs for the job user. Background: when getpwnam() fails, cron considers the user to be nonexistent, then logs an ORPHAN message and finally just ignores the crontab, permanently. By itself, this behaviour is certainly correct. cron uses the getpwnam() interface for a reason, it does not care about the stuff going on behind it, be it a /etc/passwd or LDAP lookup. However, in connection with name caching services and getpwnam()s inability to distinguish between temporary and permanent lookup errors, permanently disabling crontabs for what could theoretically be a temporary failure seems excessive, especially in light of the other (aforementioned) failure recovery enhancements recently added to the daemon. A decision should be made on whether we continue to treat *all* (since we cannot differentiate) getpwnam() failures as a permanent, fatal error or as a temporary one from which we recover. [0] https://bugs.launchpad.net/bugs/27520
signature.asc
Description: OpenPGP digital signature
