Bug 198019 - crond fails to detect changes to files in /etc/cron.d
Summary: crond fails to detect changes to files in /etc/cron.d
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: vixie-cron
Version: 6
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Marcela Mašláňová
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-07-08 02:53 UTC by James Ralston
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2006-09-08 11:52:17 UTC
Type: ---
Embargoed:


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

Description James Ralston 2006-07-08 02:53:31 UTC
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-08 03:10:43 UTC
Created attachment 132096 [details]
bugfix

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
/etc/cron.d.

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-21 02:18:39 UTC
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 16:31:28 UTC
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 11:52:17 UTC
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.