Bug 152396
| Summary: | automatic cron reload delays new jobs | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Need Real Name <lsof> |
| Component: | vixie-cron | Assignee: | Jason Vas Dias <jvdias> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7 | CC: | patrick.melo |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | vixie-cron-4.1-82.fc7 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2005-04-05 16:05:35 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Need Real Name
2005-03-29 08:02:33 UTC
(The second cat /tmp/date - the one that works - should have a time of 09:57:02) This is not a bug, but is the way cron works. CRON is not a tool for running programs at specific times - for that purpose, use at(1) . CRON is a tool for running programs at periodic intervals which must not be less than one minute (60 seconds). Every minute, cron runs jobs scheduled for that minute, and then examines its crontab locations for new, deleted or changed crontab files, and loads changed crontab files to contruct its schedule for successive minutes; so the time from making a change to the time the change takes effect will always be at least two minutes. If cron immediately executed newly created schedules every minute, it could not guarantee that at least 60 seconds elapse between job executions, a bug with previous cron versions. Hence, this bug is being closed as "not a bug". I'm not sure I understand. From the man page: "Cron then wakes up every minute, examining all stored crontabs, checking each command to see if it should be run in the current minute." So according to the man page, cron wakes up, looks a the crontab, and runs the jobs. Not doing this is a bug surely? By "stored crontabs" the man-page means "crontabs stored in memory". The way cron loads jobs at least one minute before running them means that it can guarantee that no job will run twice within 60 seconds. This was a serious bug with cron-3.0.x : bug 106578 . Ah. Well I suppose that makes more sense then. You don't want to delay all the other jobs just because cron has changed, but I still think that the behaviour doesn't match the man page. Can we reopen this bug as a bug in the man page, for not making things clear? Annoyingly, this bug also means that when you have a dieing machine with a rising load average, killing the runaway process, then disabling the cron job, doesn't disable the cron job until the next time round. Nice! I will annotate the man-page accordingly in the next cron version. RE: Comment #6 : This is NOT a bug, as explained above. If you have a dieing machine, due to a runaway cron job process A) why not do 'service crond stop' or 'reboot' rather then edit a crontab ? B) the cron job should not have been added until the process was tested . It depends how you look at it. From the programmer's point of view it isn't a
bug. From the user's, it is.
Anyway, please don't make assumptions.
In reply:
A) Why not stop the cron daemon? Why not reboot?
Because the machine was still working, if slowly.
There's no need to make things worse by killing other jobs just because
one job goes wrong.
B) logrotate is shipped by you, you test it.
*** Bug 159441 has been marked as a duplicate of this bug. *** This bug, whereby cron would reload crontab AFTER running the cron jobs (and thereby ignoring any changes less than 2 minutes old) is fixed in the current version. |