Bug 139234 - Cron does not look at new crontabs
Cron does not look at new crontabs
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: vixie-cron (Show other bugs)
3
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Vas Dias
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-11-14 06:07 EST by David Bunt
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-11-17 10:37:50 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)
Crontab1 per request (56 bytes, text/plain)
2004-11-17 08:57 EST, David Bunt
no flags Details
Crontab2 per request (56 bytes, text/plain)
2004-11-17 08:57 EST, David Bunt
no flags Details

  None (edit)
Description David Bunt 2004-11-14 06:07:19 EST
Description of problem:
Cron will not look at a changed crontab. Accepts changes from crontab
-e command, but will not run them until you stop crond and restart it.
Tried manual touch command on /var/spool/cron and /etc/cron with no
effect.

Version-Release number of selected component (if applicable):
4.1-19

How reproducible:
Upgrade core 2 install with core 3. crontab -e  change something.
Change will not execute until you restart crond.

Steps to Reproduce:
1. Upgrade core 2 install with core 3
2. crontab -e  change/alter/add entry
3. crond will ignore changes
  
Actual results:
crond ignores changes in crontab

Expected results:
crond runs changes in crontab

Additional info:
Will act normally if crond is restarted after a crontab change.
Comment 1 Jason Vas Dias 2004-11-15 10:18:29 EST
 I cannot reproduce this problem.
 Do you have SELinux enabled ?
 Perhaps this might be an issue with upgrading from FC2-FC3
 and enabling SELinux for the first time.
 You can see details of any SELinux issues with this command:
 # /usr/bin/audit2allow -l -i /var/log/messages
 If you still have a problem, please try the following:
 1. Copy the existing crontab file to /tmp/crontab1 
 2. Change the crontab file, then copy it to /tmp/crontab2
 3. Wait for enough time for the changes to take effect
 4. Verify that the changes have not taken effect, and run
    the 'audit2allow' command above
 5. Run the command:
    # ls -lZ /var/spool/cron
 6. Try:
    # /sbin/restorecon /var/spool/cron
    Then repeat making the crontab -e change and see if it
    now takes effect - do you still have a problem ?
 Then please append the /tmp/crontab[12] files, the audit2allow
 output, and the ls output to this bug report - thanks.
Comment 2 David Bunt 2004-11-17 08:55:48 EST
> I cannot reproduce this problem.

Haven't upgraded my other machines yet, so I'm not sure if I can
either on another machine.

> Do you have SELinux enabled ?

No

> You can see details of any SELinux issues with this command:
> # /usr/bin/audit2allow -l -i /var/log/messages
> If you still have a problem, please try the following:
> 1. Copy the existing crontab file to /tmp/crontab1 

ok

> 2. Change the crontab file, then copy it to /tmp/crontab2
 
ok

>3. Wait for enough time for the changes to take effect

ok

> 4. Verify that the changes have not taken effect, and run
    the 'audit2allow' command above

Nothing happened.

> 5. Run the command:
>    # ls -lZ /var/spool/cron

Got this: Sorry, this option can only be used on a SELinux kernel.

> 6. Try:
>    # /sbin/restorecon /var/spool/cron
>    Then repeat making the crontab -e change and see if it
>    now takes effect - do you still have a problem ?

No effect

> Then please append the /tmp/crontab[12] files, the audit2allow
> output, and the ls output to this bug report - thanks.


Did do this:
crontab -e     changed time
/etc/rc.d/init.d/crond stop
Stopping crond:                                            [  OK  ]
[root@gandalf tmp]# /etc/rc.d/init.d/crond stop
Stopping crond:                                            [  OK  ]
[root@gandalf tmp]# /etc/rc.d/init.d/crond stop
Stopping crond:                                            [FAILED]
[root@gandalf tmp]# /etc/rc.d/init.d/crond start
Starting crond:                                            [  OK  ]

Waited
[nfocipher@gandalf tmp]$ ls -l CronWorked.txt
-rw-r--r--  1 nfocipher nfocipher 3 Nov 17 07:58 CronWorked.txt

It works fine after a service restart. Course I had to issue the stop
command twice.
Comment 3 David Bunt 2004-11-17 08:57:06 EST
Created attachment 106887 [details]
Crontab1 per request
Comment 4 David Bunt 2004-11-17 08:57:31 EST
Created attachment 106888 [details]
Crontab2 per request
Comment 5 Jason Vas Dias 2004-11-17 10:37:50 EST
 I still can't reproduce this. 

 CRON always picks up changes after a 'crontab -e' without restart .
 
 However, cron checks for changes only when each minute elapses; ie.
 if you make a change at HH:00:30, the change is not picked up until
 HH:01:00; so you cannot schedule a job to run at the same minute
 the change is picked up (HH:01); it will only be run the next day.
 
 I followed these steps:
 1. create non root user crontab with crontab -e at 10:00:10 :
    2 10 * * * /bin/date>/tmp/cron.10_02.test

 2. Without crond restart, the change is picked up at 10:01:00 
    and the job runs at 10:02:00 . 

 3. If I now change it at 10:02:10 to:
    3 10 * * * /bin/date>/tmp/cron.10_03.test
    at 10:03:00, cron picks up the change at 10:03:00, but since
    it is already 10:03 the job is not run and would not be run 
    until tomorrow at 10:03:00. 

If I had restarted cron at say 10:02:40, the 10:03 job would have 
been run, because the job is already scheduled when the time changes 
to 10:03 .

This is the way cron has always worked; to make it work differently
(ie. to make it run new jobs scheduled to run at the same minute
they are picked up), would be a major design change
and a deviation from standard cron behaviour.

You can confirm this by tailing the /var/cron/log file when you 
make a change:

Nov 17 10:36:17 jvdsibm crond[3048]: (CRON) STARTUP (V5.0)
Nov 17 10:36:34 jvdsibm crontab[3054]: (jvdias) BEGIN EDIT (jvdias)
Nov 17 10:36:58 jvdsibm crontab[3054]: (jvdias) REPLACE (jvdias)
Nov 17 10:36:58 jvdsibm crontab[3054]: (jvdias) END EDIT (jvdias)
Nov 17 10:37:01 jvdsibm crond[3048]: (jvdias) RELOAD (cron/jvdias)
Nov 17 10:38:01 jvdsibm crond[3062]: (jvdias) CMD
(/bin/date>/tmp/cron.10_38.test)


So, cron DOES always pick up changes without being restarted.
Because of the way changes are only picked up when the next 
whole minute elapses, jobs scheduled to be run within a minute
of the change being made will not run until the next day.



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