Bug 52095 - RFE: anaconda should set cron dir timestamps correctly.
RFE: anaconda should set cron dir timestamps correctly.
Status: CLOSED DUPLICATE of bug 6175
Product: Red Hat Linux
Classification: Retired
Component: anaconda (Show other bugs)
7.3
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-08-20 10:53 EDT by greg hosler
Modified: 2007-04-18 12:36 EDT (History)
4 users (show)

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


Attachments (Terms of Use)

  None (edit)
Description greg hosler 2001-08-20 10:53:39 EDT
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
Comment 1 Glen Foster 2001-08-20 15:25:01 EDT
This defect is considered SHOULD-FIX for Fairfax.
Comment 2 Milan Kerslager 2001-08-21 04:57:10 EDT
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 17:12:17 EDT
I agree.
Comment 4 Matt Wilson 2001-09-05 18:51:28 EDT
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 12:44:35 EST
Deferring to future release.
Comment 6 greg hosler 2002-05-24 07:35:42 EDT
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)
Comment 7 Jeremy Katz 2002-12-13 17:59:38 EST

*** This bug has been marked as a duplicate of 6175 ***
Comment 8 Red Hat Bugzilla 2006-02-21 13:48:06 EST
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.