From Bugzilla Helper:
User-Agent: Mozilla/4.78 [en] (X11; U; Linux 2.4.7-2smp i686; Nav)
Description of problem:
when crond wakes up every minute, it compares the time stamps of:
to determine if it has to reload the crontabs. If either /etc/cron.d
or /etc/crontab have timestamps in the future (which WILL happen
immediately after an install, until GMT catches up to local time), then
crontabs will not be reloaded (because one of those time stamps will be
greater than /var/spool/cron, which will be current/local time.
The offending code is at "database.c" line 80 of 295
Version-Release number of selected component (if applicable):
Steps to Reproduce:
0.REPRODUCIBALITY: EVERYTIME *IMEMDIATELY* after installation.
1. do an installfrom scratch.
2. within the hr, create a user, and have that user create teh following
*/1 * * * * echo "hello world" > /tmp/greg.txt 2>&1&
at the mext minute rollover, crond will not reload the crontab (tail
-f /var/log/cron for confirmation).
Once local time passes the dates on /etc/cron.d and /etc/crontab, crontab
will start working properly.
This can be very confusing to the knowledgeable user who knows that crontab
should have changed, but didn't, within this specific time period.
Actual Results: crontab's do not ALWAYS reload when modified.
(specifically, they do not reload immediately, and for perhaps half a day
after an installation)
Expected Results: crontab's should ALWAYS reload when modified.
BIOS set to local time.
installation date/time defaults accepted.
after boot, clock is correct time, but looking at the installation
directories, they will all be slightly in the future.
Note that my time zone is GMT+8
This defect is considered SHOULD-FIX for Fairfax.
IMHO Anaconda should be fixed. As I remember, from 7.0 it *always* create
config files with GMT set instead of loading local time during installation.
This is a real problem.
I't up to somebody from RH to make a decision. Fix for Anaconda is better solution.
unfortunately, the timezone data is not always available. Without it, we won't
know how to compensate for daylight savings time or other local adjustments. We
only have that data once glibc-common is installed (in ftp/http installs).
Another solution will have to be engineered later.
Deferring to future release.
This buig can be easily resolved as follows:
in /etc/rc.d/init.d/cron add the following logic to start()
# The following code ensures that the crontab directories never
# have a timestamp in the future. (crond uses these timestamps to
# see if the crontabs need to be reloaded.
touch /tmp/crond >& /dev/null
if [ -e /tmp/crond ] ; then
if [ /etc/cron.d -nt /tmp/crond ) ]] ; then
if [ /etc/crontab -nt /tmp/crond ) ]] ; then
if [ /var/spool/cron -nt /tmp/crond ) ]] ; then
(untested, but *should* work)
*** This bug has been marked as a duplicate of 6175 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.