Bug 425041 - crontab doesn't execute in the following minute
crontab doesn't execute in the following minute
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: vixie-cron (Show other bugs)
i386 Linux
low Severity low
: ---
: ---
Assigned To: Marcela Mašláňová
Brock Organ
Depends On:
  Show dependency treegraph
Reported: 2007-12-14 10:28 EST by Eric LeBlanc
Modified: 2010-02-22 08:21 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-02-22 08:21:18 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Eric LeBlanc 2007-12-14 10:28:00 EST
Description of problem:
When we want to debug some scripts to see if they work well from the cron, we 
put a schedule that will execute in the following minute.

For example, if today is 12:30:30, we enter this in the crontab (via 
crontab -e)

31 12 * * * echo boo > /tmp/test

Meaning that this command should be executed at 12:31:00.  It does not work.  
However, if we put 2 more minute, it works, like this:

32 12 * * * echo boo > /tmp/test

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

I don't know if it's a bug or a security feature but we lost a couple of hours 
before figuring out that it's was the cron the issue, not the script...  

It seems that the cron first check if there are some modifications and if yes, 
it reload the config and then execute the commands in the next minute.

RH3 update 6 and older are not affected by this.

How reproducible:

Steps to Reproduce:
1. crontab -e
2. Put the following minute (ie: if today is 12:30:30, use 31 12 * * *)

Actual results:
The crontab doesn't execute something in the next minute.

Use five asterisks instead of the hour ( * * * * * echo boo > /tmp/test ).
Comment 1 Marcela Mašláňová 2007-12-18 07:42:46 EST
In the latest release of vixie-cron is the job runned with one minute delay. The
reason is that the cron sleeps and wake up every minute to reschedule jobs. The
only one minute delay instead of two minutes delay could be easily backported.
Comment 2 Marcela Mašláňová 2010-02-22 08:21:18 EST
This issue was fixed in next releases. I suggest update to newer release.

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