Bug 198019 - crond fails to detect changes to files in /etc/cron.d
crond fails to detect changes to files in /etc/cron.d
Product: Fedora
Classification: Fedora
Component: vixie-cron (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Marcela Mašláňová
Brock Organ
Depends On:
  Show dependency treegraph
Reported: 2006-07-07 22:53 EDT by James Ralston
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-09-08 07:52:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
bugfix (5.95 KB, patch)
2006-07-07 23:10 EDT, James Ralston
no flags Details | Diff

  None (edit)
Description James Ralston 2006-07-07 22:53:31 EDT
The test that crond uses to check whether crontab files in /etc/cron.d have
changed is flawed.

The problem is in database.c.  The load_database() function performs a while
loop for each dirent in RH_CROND_DIR, constructing filenames to pass to
process_crontab().  However, load_database() reuses the crond_stat buffer from
the stat on RH_CROND_DIR when it calls process_crontab() on the constructed
filename.  Therefore, process_crontab() is *not* looking at the mtime of the
crontab, but at the mtime of /etc/cron.d instead.

The symptom of this bug is that crond won't realize that a crontab in
/etc/cron.d has changed unless *both* the mtime of the /etc/cron.d directory and
the mtime of the crontab file itself change while cron is sleeping.

What makes this bug so insidious is that most editors (emacs, vi, et. al.) will
create temporary files in the same directory as the file being edited, which
will change the mtime of /etc/cron.d as a side-effect.  So, if you edit crontab
files in /etc/cron.d directly, you won't see the bug.  If, however, you are
editing a copy of the crontab file in a different directory, depending on how
you install it into /etc/cron.d, the mtime of /etc/cron.d may or may not be
changed.  (E.g., the "cp" command will simply truncate the existing file and
open it for writing, which won't change the mtime of /etc/cron.d.)

I've filed this bug against FC6test1, but it affects all versions of Fedora Core
and Red Hat Enterprise Linux.
Comment 1 James Ralston 2006-07-07 23:10:43 EDT
Created attachment 132096 [details]

This patch changes the behavior of crond as follows: not only is the mtime of
/etc/cron.d examined (to detect crontabs that have been unlinked from
/etc/cron.d), but the mtimes of all crontabs in /etc/cron.d are checked as
well.  The most recent mtime is collectively considered to be the "overall"
mtime of /etc/cron.d.

Furthermore, when process_crontab is called, the stat buffer that is passed is
the one obtained from calling stat() on the individual crontab file, not

As a result, crond will correctly detect any changes to crontabs in /etc/cron.d
that update the mtime, regardless of whether the mtime for /etc/cron.d changes.
 Changes that update the mtime for /etc/cron.d (adding new crontabs, unlinking
existing crontabs) will continue to be properly detected.
Comment 2 Jason Vas Dias 2006-07-20 22:18:39 EDT
Yes, I see the problem - amazing it never surfaced until now; I think earlier
UNIX-ish systems DID always set the mtime of the containing directory when
a contained file mtime changed - modern linux evidently does not:
  # echo '* * * * * date' > /var/spool/cron/root
will NOT make cron pick up the changed /var/spool/cron/root file, because the
mtime of /var/spool/cron will not have changed.

Users are always recommended to use crontab(1) to update crontab files - ie.
  # echo '* * * * * date' | crontab
WOULD make the old crond pick up the change.

Thanks for your patch - I've adapted it to also check /var/spool/cron, as well
as /etc/cron.d, and to clean up some other discrepancies.

This issue is now fixed in vixie-cron-4.1-58+ , now submitted to rawhide (soon
to be FC-6) - if no problems arise in the next two weeks or so, I'll submit
this change to FC-5 (and consider submitting to RHEL-{3,4} vixie-cron also).
Comment 3 James Ralston 2006-07-24 12:31:28 EDT
I'm glad the patch was useful.

Since "crontab -e" was the defined interface for editing files in
/var/spool/cron, this problem wouldn't have surfaced until Red Hat added the
/etc/cron.d patches.  Add even then, the most common mechanism for things being
changed in /etc/cron.d is probably rpm, which (due to the nature of how rpm
performs updates) will always cause the directory mtime to be updated.

Really, about the only way to reproduce the problem is to do what I did: use
"cp" to update an already-existing file in /etc/cron.d  :p
Comment 4 Marcela Mašláňová 2006-09-08 07:52:17 EDT
It has been pushed for update to FC-5 vixie-cron-4.1-58.fc5.
In FC-6 has been fixed in vixie-cron-4.1-58.fc6

Note You need to log in before you can comment on or make changes to this bug.