[Bug 224537] cron uses directory mtime to notice changes - not sufficient - file changes don't change dir mtime

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224537

            Bug ID: 224537
           Summary: cron uses directory mtime to notice changes - not
                    sufficient - file changes don't change dir mtime
           Product: Base System
           Version: 11.1-RELEASE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: bin
          Assignee: freebsd-bugs at FreeBSD.org
          Reporter: jsellens at syonex.com

/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!

-- 
You are receiving this mail because:
You are the assignee for the bug.