Bugzilla – Bug 972984
cron.daily jobs not executed daily when timestamps are backed up (script used wrong timestamps)
Last modified: 2017-01-23 12:06:55 UTC
Created attachment 670766 [details]
Fixed version of /usr/lib/cron/run-crons
Jobs configured to run daily are not executed every day when the timestamps in "lastrun" are backed up daily:
The backup software used utime() to reset the file's access time, thereby updating the files creating time to the time of change.
As the script used the creation time of the inode instead of the modification time of the file (programming error), a backup of the timestamp file causes the daily jobs to be skipped for 24 hours.
So if you backup your most important systems daily, cron.daily jobs are never run!
Note: The script also uses "date -r file", and that command uses the correct time stamp (modification time).
I changed the script to fix this issue (see attachment), also adding TIME_EXT (the type of job being run) to the log messages.
Another note: This may be a duplicate of Bug 960716, but the former had been closed as being invalid while it seems to address the same issue.
We ran into a very similar problem on SLES 11 SP4. In our case, backup software is updates atime, mtime and ctime on "/var/spool/cron/lastrun/cron.daily" and "/var/lib/logrotate.status". So, we can't use Ulrich's version of "/usr/lib/cron/run-crons", but it was very helpful for determining what was actually causing the problem.
Similar problem. Antivirus software updating ctime with every scan...
This is the same issue as bug 980873 that we've just closed as invalid. Using zero-length lock files is common Unix practice and we believe that this is the problem with third-party software that shouldn't alter the ctime timestamp.
I'm sorry, but I'm closing this issue as invalid.
(In reply to Ulrich Windl from comment #0)
> Another note: This may be a duplicate of Bug 960716, but the former had been
> closed as being invalid while it seems to address the same issue.
Btw. That was a little bit different issue about an inability to set the custom times for hourly, daily, weekly and monthly scripts with the current version of the run-crons script. However, we figured out that this is possible and the SLE12 manual provides a solution (see comment 2). So no changes in the run-crons script were needed.
(In reply to Kristyna Streitova from comment #3)
> This is the same issue as bug 980873 that we've just closed as invalid.
That bug is not public, so I can't learn anything from that.
> Using zero-length lock files is common Unix practice and we believe that
> this is the problem with third-party software that shouldn't alter the ctime
This is one point of view, but did you ever take the time to read about the differences between "ctime" and "mtime"? If you change the contents of a file, the "mtime" is changed, but if you change the i-node's attributes (e.g. permissions), the "ctime" is changed.
> I'm sorry, but I'm closing this issue as invalid.
Actually the only reason I would understand for not fixing this bug is personal stubbornness: Would applying the fix in attachment 670766 [details] break anything?
Yesterday I discovered a case where cron.daily jobs were last run on May 11th.
My view on this bug is: The script was wrong all the time, but accidentially it did work. As Kernighan and Plaugher said in their book about software bugs: "If you are lucky, it never works; if you have bad luck, it works in most cases." (cited from fuzzy memory)
Created attachment 711225 [details]
SOURCE RPM for fixing /usr/lib/cron/run-crons
After thinking a long time how to provide an RPM to fix another bad RPM, I found this solution: Patch on install, possibly repeating it after updates via cron, unpatch on uninstall.
The final package includes two patches: One (mtime.patch) fixes the bug described, the other (logger.patch) improves logging (you maight want to change the setting of SYSLOG_ON_NO_ERROR to "yes" in /etc/sysconfig/cron to see the effects.
After install the package will provide the following files:
drwxr-xr-x 2 root root 0 Jan 23 12:43 /usr/lib/cron/fix
-r--r--r-- 1 root root 1390 Jan 23 12:35 /usr/lib/cron/fix/logger.patch
-r--r--r-- 1 root root 26 Jan 20 13:06 /usr/lib/cron/fix/logger.patch.pattern
-r--r--r-- 1 root root 1681 Jan 23 12:35 /usr/lib/cron/fix/mtime.patch
-r--r--r-- 1 root root 36 Jan 20 13:06 /usr/lib/cron/fix/mtime.patch.pattern
-r-xr-xr-x 1 root root 1121 Jan 20 13:52 /usr/lib/cron/fix/patch-run-crons
-rw-r--r-- 1 root root 51 Jan 20 14:20 /usr/lib/cron/fix/run-crons-fix
After installation additional files will be created in /usr/lib/cron/: run-crons.SuSE (backup of the original run-crons)
run-crons~<some number> (additional backup of run-crons before having applied a patch)
Maybe some people will find this useful...