Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 163341 - crond failed to parse entry in a crontab
Summary: crond failed to parse entry in a crontab
Status: CLOSED DUPLICATE of bug 137962
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: vixie-cron
Version: 3.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jason Vas Dias
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2005-07-15 11:36 UTC by Hiroki Taira
Modified: 2007-11-30 22:07 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-07-15 13:54:58 UTC
Target Upstream Version:

Attachments (Terms of Use)
crontab file (deleted)
2005-07-15 11:36 UTC, Hiroki Taira
no flags Details

Description Hiroki Taira 2005-07-15 11:36:00 UTC
Description of problem:

crond doesn't fork any commands
after entering entries that can't be parsed.

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


How reproducible:

Creating crontab file in which there are entries
that can't be parsed.

Steps to Reproduce:

1. create the file named "/etc/cron.d/clean_tmp"
2. input the entry like following in the file.

0 */0,6,12,18 * * * root find /usr/local/hde/lc/backup/tmp/session -name ".[0-
9a-f]*" -a -cmin +360 -exec rm -rf "{}" \; >/dev/null 2>&1
Actual results:

Any commands in crontab are not executed ever.

Expected results:

same above.

Additional info:

After changing the entry following, crond has got started again.

0 0,6,12,18 * * * root find /usr/local/hde/lc/backup/tmp/session -name ".[0-9a-
f]*" -a -cmin +360 -exec rm -rf "{}" \; >/dev/null 2>&1

Comment 1 Hiroki Taira 2005-07-15 11:36:01 UTC
Created attachment 116793 [details]
crontab file

Comment 2 Jason Vas Dias 2005-07-15 13:54:58 UTC
I think cron was confused by the "0 */0..." entry, which is pretty meaningless:
"every hour, skipping 0 hours" - a synonym for "0 0..." .
What was your intention with the "0 */0" entry ?
Yes, cron needs improvement in reporting crontab parse errors - currently, it
simply ignores them, as have all previous versions of cron.
I am currently working on an enhanced version of cron that will report cron
syntax errors, a feature that has been requested before: bug 137962 .


*** This bug has been marked as a duplicate of 137962 ***

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