Bug 224537

Summary: cron uses directory mtime to notice changes - not sufficient - file changes don't change dir mtime
Product: Base System Reporter: jsellens
Component: binAssignee: Kyle Evans <kevans>
Status: Closed Overcome By Events    
Severity: Affects Some People CC: bugs, jamie, kevans
Priority: ---    
Version: 11.1-RELEASE   
Hardware: Any   
OS: Any   

Description jsellens 2017-12-23 08:37:26 UTC
/usr/sbin/cron allows multiple files in /etc/cron.d and /usr/local/etc/cron.d and uses the mtime of the directory as an indicator of when to reload the cron files.

In cron/database.c in load_database() at around line 100, the comment is:

        /* if spooldir's mtime has not changed, we don't need to fiddle with
         * the database.

and the statbuf.st_mtime is compared to the previous version.

If a file in a directory changes, the mtime on the directory does not change, so changes to files in cron.d directories are often not noticed.

Repeat by putting a cron file in /etc/cron.d, then using echo or cat to add an additional entry and notice that the additional entry does not run.  Similarly, use vi to edit the file, the directory's mtime does not change, and cron file changes are not loaded.

The cron(8) man page says: "Thus cron need not be restarted whenever a crontab file is modified." which is incorrect.  It mentions that crontab(1) will update the directory time, but crontab(1) can't be used with /etc/cron.d or /usr/local/etc/cron.d files.

Perhaps the code could compute and compare a checksum on the directory, or a checksum on the results of opendir() / readdir() , rather than looking only at the directory mtime?

(I ran into this when puppet was updating files in /etc/cron.d and the commands being run were not changing.)

Thanks!
Comment 1 Jamie Landeg-Jones 2019-10-26 12:10:37 UTC
I stumbled on this bug whilst searching for something loosely related.

This bug is incorrect.

The "spooldir" you reference applies to the per-user tabs in /var/spool/cron/tabs

The part that deals with timestamps on files in /etc/cron.d / /usr/local/etc/cron.d refers to SYSCRONTABS, and is the section before which you quoted, starting roughly 30 lines earlier, and they are processed approx 20 lines after the bit you quoted.

Cheers!
Comment 2 Kyle Evans freebsd_committer freebsd_triage 2019-12-26 21:53:15 UTC
Hi,

Sorry that I missed this; by now this has been OBE. This was fixed in r332429 (prior to stable/12 branching) and MFC'd to stable/11 in r332747 (prior to 11.2-RELEASE) thus the fix should be available in all supported versions/branches.

Thanks for the report!

Kyle Evans