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.
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.
> 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.
Created attachment 106887 [details] Crontab1 per request
Created attachment 106888 [details] Crontab2 per request
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.