This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 137962 - Poor error handling for bad lines in system crontab
Poor error handling for bad lines in system crontab
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: cronie (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Marcela Mašláňová
Brock Organ
: Reopened
: 163341 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-11-03 05:34 EST by Need Real Name
Modified: 2008-01-31 06:27 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-01-31 06:27:38 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 Need Real Name 2004-11-03 05:34:37 EST
User-Agent:       
Build Identifier: 

The default crontab file contains:
01 * * * * root run-parts /etc/cron.hourly
where "root" is the user to run with.

The ability to specify the user to run the command with doesn't seem to be
documented in the man pages (or on the RHEL3 cron web page).

If the user to run the command with does not exist, no error message is ever given.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.
Comment 1 Need Real Name 2004-11-03 05:53:27 EST
Apologies. man 5 crontab documents this ("man crontab" does not).

Adjusting bug.

"If the user to run the command with does not exist, no error message is ever
given."
Comment 2 Need Real Name 2004-11-04 10:04:09 EST
Cron will also not complain if a command does not exist.
e.g. an entry like
* * * * * /bin/sdgsdghdshg.sh

will not be complained about.
Comment 3 Jason Vas Dias 2004-11-04 11:37:32 EST
 I agree that cron should be more informative about job parsing errors.
 This is legacy behaviour - all vixie-cron releases have behaved this
 way. 
 The next release (vixie-cron-4.1-20) will emit error messages for 
 job parse errors to /var/log/cron .
Comment 4 Need Real Name 2005-03-29 02:53:33 EST
On FC4T1, vixie-cron 4.1-26_FC4, I don't seem to get any errors logged to
/var/log/cron for a mailformed line, or a non-existant command.

I checked the changelog, but couldn't see a reference to this bug.
Did the "parsing errors" update ever get in? Thanks.
Comment 5 Jason Vas Dias 2005-07-15 09:55:07 EDT
*** Bug 163341 has been marked as a duplicate of this bug. ***
Comment 6 Need Real Name 2005-10-24 17:35:31 EDT
Hi.
Thanks for adding the bad lines reporting, but it isn't working for me yet.

$ rpm -q vixie-cron
vixie-cron-4.1-36.FC4
$ tail -1 /etc/crontab
esgsdgsdgdsgsdgdsgds

cron sees the change, but doesn't log a parse error.
Oct 24 23:36:01 localhost crond[2391]: (*system*) RELOAD (/etc/crontab)

Here is the bad line:
$ tail -1 /etc/crontab
esgsdgsdgdsgsdgdsgds
Comment 7 Need Real Name 2006-01-25 05:23:07 EST
I can't see the error reporting in vixie-cron 4.1-44.

echo "fdioufsduigioju" > /etc/crontab

shows no errors in /var/log/messages
Comment 8 Marcela Mašláňová 2006-09-14 10:10:04 EDT
Me too. I work on better log files in at/crond. For now I can't say in which 
version will be everything allright.
Comment 9 Need Real Name 2006-10-16 16:01:24 EDT
This is still broken, and annoying too, because cron seems to treat the macro
times @hourly, @daily differently from "real" times.
Comment 10 Need Real Name 2006-10-16 16:04:23 EDT
>> /etc/crontab(In reply to comment #7)
> echo "fdioufsduigioju" > /etc/crontab

Should be:

echo "fdioufsduigioju" >> /etc/crontab
Comment 11 Marcela Mašláňová 2006-11-29 06:29:03 EST
Comment#10: you can't edit crontab this way, beacuse it doesn't install the
table. If you make echo "fdioufsduigioju" >> /etc/crontab and then crontab -e
you'll see it's still used the old installed table.
You can install table only crontab -e.

/var/log/cron : I thought about it and I don't plan log everything into log,
'cause log will be looking messy. The main way of cron functionality is sending
output by mail.

What's the precise problem with @daily etc.?

Comment 12 Need Real Name 2006-11-29 08:59:39 EST
(In reply to comment #11)
> Comment#10: you can't edit crontab this way, beacuse it doesn't install the
> table.

I don't understand what you mean. crontab will reload the file when it stats the
file every minute.

man crond agrees:

       which have changed.  Thus cron need not be restarted whenever a crontab
       file is modified.  Note that the Crontab(1) command updates the modtime
       of the spool directory whenever it changes a crontab.

> What's the precise problem with @daily etc.?

I think the problem with this is that a time macro followed by a username and
command does not work, but a normal time followed by a username and a command
does (system crontab).
Comment 13 Marcela Mašláňová 2006-11-29 09:18:17 EST
Yes, crontab -e edit crontab, changed and use it, but if you do 
echo "fdioufsduigioju" >> /etc/crontab then you don't install new crontab table,
only rewrite line in /etc/crontab/ 
crontab -e is correct way for scheduling jobs.

@daily, @hourly etc. run ok, you need install anacron, vixie-cron and crontabs
for full functionality.
Comment 14 Need Real Name 2006-11-29 11:55:11 EST
(In reply to comment #13)
> if you do 
> echo "fdioufsduigioju" >> /etc/crontab then you don't install new crontab 

But the man page disagrees, crond stats the crontab files every minute and
re-reads them if they have changed.

Where does it say this?

> @daily, @hourly etc. run ok, you need install anacron,
> vixie-cron and crontabs for full functionality.

But that's not the problem either.
@daily, @hourly, etc already work. The problem is that the @daily macro (etc)
does not work when used with a username next to it.
e.g.
# works:
@daily /bin/date
# fails:
@daily someuser /bin/date
Comment 15 Marcela Mašláňová 2006-12-12 08:04:06 EST
> # fails:
> @daily someuser /bin/date
I don't know, which version of anacron do you have. It's working.

> echo "fdioufsduigioju" >> /etc/crontab
This is not in crontab, use options man crontab
Comment 16 Need Real Name 2006-12-12 11:52:03 EST
Erm, okay..

I have a problem with crontab not behaving as advertised.
I report the bug, and you close it saying the bug doesn't exist, but you don't
say which version the bug is fixed in.

I am using
 vixie-cron-4.1-64.fc6
 anacron-2.3-44.fc6
and the bug exists in this version.

> > echo "fdioufsduigioju" >> /etc/crontab
> This is not in crontab, use options man crontab

I dont know what you mean.

Going back to a previous comment. there is no installation of a crontab
necessary, it hasn't been necessary for years. The man page even says this.

At the moment there remain two bugs:
1. Invalid lines in crontab are silently ignored.
2. Time macros with usernames do not work.
Comment 17 Marcela Mašláňová 2006-12-12 12:34:45 EST
I have:
rpm -q 
vixie-cron anacron
vixie-cron-4.1-64.fc6
anacron-2.3-41.fc6

1. where in man crontab did you find this? > echo "fdioufsduigioju" >> /etc/crontab
How I can check if script if you want run exist and will exist in time of being
run. It's not possible. 
2. Ok time macros with username don't work, but when you read that it have to work?
in man crontab: If the -u option is given, it specifies the name of the user
whose crontab is  to  be  tweaked. So you have to write (with permission to use)
for example: crontab -u user -e
Comment 18 Need Real Name 2006-12-12 12:48:30 EST
We covered this in comment #1. But, to answer your questions:

1. Linux apps works by doing nothing if they are successful, and complaining
otherwise. crontab does not complain otherwise. If I enter garbage into the
crontab, it does not complain, but it should. In Comment 3, this Jason Vas Dias
agreed me on this.

2. man 5 crontab:
[snip]
Each line has five time and date fields, followed by a user name if
this is  the  system  crontab  file, followed  by  a  command. 
[snip]
These  special  time  specification  "nicknames"  are  supported, which
replace the 5 initial time and date fields, and are prefixed by the ’@’
character

As for reloading cron:
"cron(8) examines cron entries once every minute."
 -- man 5 crontab
Comment 19 Marcela Mašláňová 2007-08-21 03:40:38 EDT
I try answer all your question. I see only problem in manual page, which I'll
try update.

1. jobs with nickname = @daily are running ok, but you have to look if it's
system crontab in /etc/cron.d/some_job or users crontab (crontab -e -u user).
The system crontab wait something like: time USER command.
The users crontab wait: time command
because the user is for users crontab already known.

2. Using /etc/crontab for cron jobs isn't suggested. From this file are runnig
jobs like daily, weekly,...

3. The control of stdin isn't possible. The user has to control date of cron job
itself, he must to know when. And the command can't be controlled. The job could
or couldn't exist in time, when is crontab filled. 
Difficult commands like: 
1 0 * * * root cd /etc/scripts/backup; /usr/bin/php backup.php > /etc/backup/log
2>&1 
can't be controlled at all.
Comment 20 Need Real Name 2007-08-21 13:32:10 EDT
I don't agree with you, so I've reopened this.

Why don't I agree with you? Because you believe the crontab file cannot be
checked for problems. This is nonsense.

For the system crontab, the format is
NUMBERS USER COMMAND
With space(s) or tab(s) as separators.
Therefore, if the first five fields are not integers (e.g. 2), or time ranges
(e.g. 09-18), or the first five fields are not a time value (e.g. @daily) there
is a problem.
After that, the USER field must contain a username. If the username doesn't
exist, there is a problem.
After that, the command field must EXIST, but obviously the COMMAND field cannot
be checked more thoroughly.

For a user crontab, the same arguments apply minus the USER field.
Comment 21 Marcela Mašláňová 2007-10-09 05:36:10 EDT
Ok, I fix testing of crontabs /etc/cron.d/*. It's in upstream version of cron,
fix will be in the next release of cron. I suppose it'll be in F-9.
Comment 22 Need Real Name 2007-11-24 15:28:37 EST
This is not fixed.

Try this, from comment #7 above:
 echo "fdioufsduigioju" >> /etc/crontab

Do you get an error message? Where?
Comment 23 Marcela Mašláňová 2007-11-27 07:25:14 EST
Nov 27 13:15:55 neco crond[16807]: (CRON) STARTUP (4.3)
Nov 27 13:15:55 neco crond[16807]: CRON: error in (/etc/crontab) problem is (bad
minute)
Nov 27 13:16:01 neco CROND[16816]: (root) CMD (id -a > /var/tmp/out.txt)
Nov 27 13:16:01 neco CROND[16817]: (root) CMD (touch /tmp/root)
Nov 27 13:16:01 neco CROND[16819]: (marca) CMD (touch /tmp/marca)

The error message can't be print out immediately, because cron tables are
checked every minute. So when the crond check the tables and found problem, it
logs it into /var/log/cron

As I said before /etc/crontab is system table and was't mend for users jobs.
Mych better is: echo "fdioufsduigioju" >> /etc/cron.d/some_job

It's now in devel version fixed in vixie-cron-4.3-2.fc9.
Comment 24 Need Real Name 2007-11-27 13:29:34 EST
> As I said before /etc/crontab is system table and was't mend for users jobs.

In that case I refer you, again, to man 5 crontab. See comment 18.

Please stop closing this bug, it's not fixed yet.
Comment 25 Marcela Mašláňová 2007-11-28 03:16:50 EST
In this case you should say precisely, what I have to fix. 
Comment 26 Need Real Name 2007-11-28 14:56:08 EST
There are two different formats for the system crontab: one with a user and one
without. If there is no user specified, the entry is run as root.

On top of this, the five time fields can be replaced with a time macro, e.g.
@weekly.

crontab should complain whenever the system crontab does not match one of these
formats.

Comment 27 Marcela Mašláňová 2007-11-29 03:29:09 EST
Did you test it?

man 5 crontab
> Each line has five time and date fields, followed by a user name if this is
the > system crontab file, followed by a command.

If you don't write user name in system crontab, it won't work. That's the
standard cron table, which won't be changed.

That's my last comment here.

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