Bug 145910 - vixie-cron fails to run jobs in /etc/crontab
vixie-cron fails to run jobs in /etc/crontab
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: vixie-cron (Show other bugs)
3
All Linux
medium Severity high
: ---
: ---
Assigned To: Jason Vas Dias
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-01-23 15:54 EST by Mark Mathewson
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: 2005-01-24 09:33:46 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)

  None (edit)
Description Mark Mathewson 2005-01-23 15:54:00 EST
Description of problem:

vixie-cron fails to run jobs in /etc/crontab.

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

vixie-cron-4.1-19.i386 and vixie-cron-4.1-20_FC3.i386

How reproducible:

100% every time

Steps to Reproduce:
1. Enter a new job in /etc/crontab for a minute away
  
Actual results:

Cron log shows /etc/crontab being re-read. But no other action is
taken. No error message results. No e-mail is sent.

Expected results:

Cron log should show the command being executed, it should do its work
and an e-mail should be sent confirming that.

Additional info:

To prove it's not some wierd setup gremlin (which is vanilla - only
installed today - so unlikely) I reverted to vixie-cron-3.0.1-87.i386
from FC2 and this works perfectly every time.
Comment 1 Jason Vas Dias 2005-01-24 09:33:46 EST
What was the new command you entered into /etc/crontab that was not
executed?

Note that vixie-cron-4.1 now enforces the rule that all system crontab
jobs MUST have a user sixth field - if the sixth field is not a valid
user, the job line is rejected as invalid input, so a command like:
    * * * * * /bin/date>/tmp/cron
would be rejected; you would need to say: 
    * * * * * root /bin/date>/tmp/cron
if the command is in (*system*) crontab (/etc/crontab, /etc/cron.d/*).

Also, vixie-cron-4.1 differs from previous versions in that commands
are eligible for execution once the next whole minute after they are
loaded has elapsed.
Note also that commands are always loaded when a complete minute has
elapsed by the local clock.
So if you edit and save a crontab file at 00:00:30, crond loads the
new crontab file at 00:01:00, but no changes take effect until 
00:02:00.
So if you try to make a command run at one minute past each hour,
with a line like:
   * 1 * * * root /bin/date>/tmp/cron.test
and save the file at 00:00:30, the first time the command would be
executed is 01:01:00 .
You can verify this by editing the crontab file and checking that
there is a RELOAD message in /var/log/cron - the command becomes
eligible for scheduling on the next whole minute after the RELOAD.

This can be confusing if you are editing a crontab file and expect
results to be generated immediately. 
Note that cron is a tool for PERIODIC command execution, not for 
scheduling jobs to run at a certain fixed time - for that purpose,
use at(1) .

I've tested and retested this, and have never observed a crontab 
change not taking effect with vixie-cron-4.1 .

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