Bug 972984 - cron.daily jobs not executed daily when timestamps are backed up (script used wrong timestamps)
cron.daily jobs not executed daily when timestamps are backed up (script used...
Status: RESOLVED INVALID
Classification: openSUSE
Product: openSUSE Distribution
Classification: openSUSE
Component: Basesystem
Leap 42.1
All openSUSE 42.1
: P5 - None : Normal (vote)
: ---
Assigned To: Kristyna Streitova
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2016-03-29 10:48 UTC by Ulrich Windl
Modified: 2017-01-23 12:06 UTC (History)
2 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
Fixed version of /usr/lib/cron/run-crons (7.59 KB, application/x-shellscript)
2016-03-29 10:48 UTC, Ulrich Windl
Details
SOURCE RPM for fixing /usr/lib/cron/run-crons (7.46 KB, application/x-rpm)
2017-01-23 12:06 UTC, Ulrich Windl
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ulrich Windl 2016-03-29 10:48:22 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.
Comment 1 Andrew Chace 2016-04-18 20:30:20 UTC
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.
Comment 2 Vojtech Lacina 2016-05-20 10:54:19 UTC
Similar problem. Antivirus software updating ctime with every scan...
Comment 3 Kristyna Streitova 2016-06-02 14:02:23 UTC
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.
Comment 4 Ulrich Windl 2016-06-03 06:14:30 UTC
(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
> timestamp.

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)
Comment 5 Ulrich Windl 2017-01-23 12:06:55 UTC
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...