Justin Pryzby wrote: > #433609 - Cron does not recover from broken links > http://bugs.debian.org./433609 > > Debian cron seems to be patched to avoid spinning up laptop > harddrives. The logic is: > > if no spoolfiles have been added or removed (the parent's mtime is > unchanged) && no previously-existing crontabs were updated, don't > update the database. Otherwise, readdir() and update the database. > > In this case, fixing the target of the symbolic link by creating a > pathname that didn't exist without touching the symbolic link itself > doesn't cause cron to reread the crontabs: since the symbolic link was > dangling when the dir was most-recently read, that entry wasn't added > to the list of crontabs.
This analysis was correct. > Is it a bug? I don't know, since I can't immediately come up with a > better behavior. Perhaps changing the crontab datastructures to > include filesnames (rather than constructing them dynamically as > needed) and including a member for "disabled" cronjobs. Periodically > (every run?) stating the disabled jobs and either ignoring them or > re-reading them and setting them to active could avoid the need to do > a full readdir. A fix has been committed to SVN. Crontabs from broken symlinks get added as empty crontabs with mtime settings guaranteed to cause an update attempt the next time cron wakes up. This approach was chosen to accommodate a future planned fix. Thanks again, Justin, for your excellent analysis! Christian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
