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: /etc/cron.d /etc/crontab /var/spool/cron 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): How reproducible: Always 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 crontab: */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. Additional info: 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.
I agree.
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 touch /etc/cron.d fi if [ /etc/crontab -nt /tmp/crond ) ]] ; then touch /etc/crontab fi if [ /var/spool/cron -nt /tmp/crond ) ]] ; then /var/spool/cron fi rm /tmp/crond fi (untested, but *should* work)
*** This bug has been marked as a duplicate of 6175 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.