2012-04-23 Suddenly, I noticed that my cron.daily, cron.weekly and cron.monthly scripts were not executed. I should have noticed earlier. They contain important operations, which simply were not run during the last weeks. But how come? My investigation brought me to /etc/crontab with entries like: 37 4 * * * root test -x /usr/sbin/anacron || \ ( cd / && run-parts --report /etc/cron.daily ) They mean, that if anacron is available, then cron should not care to run cron.daily etc. The problem is that the check is only for the existence of anacron on the machine, but if it actually runs. My anacron was deactivated. On a server that should be on- line 24/7, there's no need for anacron anyway. Don't know why it was installed at all. So, my server failed to generate important backups (and I failed to notice the absence of ``backup done'' mails). The problem was that cron was told to check for the existence for anacron, but not if it takes responsibility for actually running the jobs. How should this problem be solved? I don't have a solution at hand, but let me discuss the topic. The problem here is clearly, that the check needed and the check performed don't match. Maybe the better approach for anacron would be to only care for the the times when the system was down, thus covering a time space disjunct to cron's. Reboot date are easy to get, but exact shutdown times might be difficult or even impossible to get. But as anacron usually cares for jobs in daily or longer intervals it relaxes the problem. Note that this only concerns the default setup of processing cron.daily, cron.weekly, cron.monthly reliably. The administator can configure any setup he likes, of course. In summary, I think that splitting the time intervals for which cron and anacron take responsibility in disjunct parts is the better approach. Anacron would only process the jobs scheduled for cron, that cron didn't process due to system downtime. Actu- ally, anacron would only need to find out which jobs were missed and reissue them, possibly using at(8). This would avoid the problem I've suffered from: Communication failure on the question who is responsible for a certain task when both services could process it. Simple and clear rules solve such issues, even better if the design is already orthogonal. But of course, when the program checks something else but what it wants to know, then it can only succeed by accident. ;-) http://marmaro.de/lue/ markus schnalke