Bug 52095 - RFE: anaconda should set cron dir timestamps correctly.
Summary: RFE: anaconda should set cron dir timestamps correctly.
Status: CLOSED DUPLICATE of bug 6175
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: anaconda   
(Show other bugs)
Version: 7.3
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2001-08-20 14:53 UTC by greg hosler
Modified: 2007-04-18 16:36 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-02-21 18:48:06 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description greg hosler 2001-08-20 14:53:39 UTC
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):

How reproducible:

Steps to Reproduce:
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.

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

Comment 1 Glen Foster 2001-08-20 19:25:01 UTC
This defect is considered SHOULD-FIX for Fairfax.

Comment 2 Milan Kerslager 2001-08-21 08:57:10 UTC
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.

Comment 3 Crutcher Dunnavant 2001-09-05 21:12:17 UTC
I agree.

Comment 4 Matt Wilson 2001-09-05 22:51:28 UTC
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.

Comment 5 Michael Fulbright 2002-03-26 17:44:35 UTC
Deferring to future release.

Comment 6 greg hosler 2002-05-24 11:35:42 UTC
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
        if [ /etc/crontab -nt /tmp/crond ) ]] ; then
            touch /etc/crontab
        if [ /var/spool/cron -nt /tmp/crond ) ]] ; then
        rm /tmp/crond 

(untested, but *should* work)

Comment 7 Jeremy Katz 2002-12-13 22:59:38 UTC

*** This bug has been marked as a duplicate of 6175 ***

Comment 8 Red Hat Bugzilla 2006-02-21 18:48:06 UTC
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

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