Bug 172096 - crontab task fail to run withour restart crond
Summary: crontab task fail to run withour restart crond
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: vixie-cron
Version: 4.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Jason Vas Dias
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-10-31 13:19 UTC by Leon Li
Modified: 2007-11-30 22:07 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-10-31 16:07:47 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Leon Li 2005-10-31 13:19:46 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; zh-CN; rv:1.7.10) Gecko/20050717 Firefox/1.0.6

Description of problem:
I add a new cron task as following:

13 21 * * * ps ax > /tmp/ps.log

The task do not run and there is no notification email.

But after I restart crond service: 

service crond restart

The cron task runs well.


Version-Release number of selected component (if applicable):
vixie-cron-4.1-20_EL

How reproducible:
Always

Steps to Reproduce:
1. add a new crontab task  crontab -e : 14 17 * * * ps ax > /tmp/rootps.log
2.
3.
  

Actual Results:  The task failed to run without restart crond

Additional info:

Comment 1 Jason Vas Dias 2005-10-31 16:07:47 UTC
Actually, I think you'll find that if you wait at least 2 minutes after making
the update, it will take effect without crond restart.
Currently, crond works by loading any updates when the minute changes ; 
e.g. at 12:00:00, 12:01:00, and then scheduling the jobs to be run at
successive minutes, so if a job is loaded at 12:00, it will not be run
until 12:01:00 .
So if your '14 17 * * *' job was updated between 17:14:00 and 17:15:59, 
it would only be loaded at 17:15:00, and would not be run until 17:15 the 
next day .
I am looking at changing this with enhancements to vixie-cron-4.1, which by
default behaves this way, but as the updates always do take effect, this is
not a bug. If you are finding that an update does not take effect within two
minutes, which I cannot reproduce, please re-open this bug.


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