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.
Steps to Reproduce:
Apologies. man 5 crontab documents this ("man crontab" does not).
"If the user to run the command with does not exist, no error message is ever
Cron will also not complain if a command does not exist.
e.g. an entry like
* * * * * /bin/sdgsdghdshg.sh
will not be complained about.
I agree that cron should be more informative about job parsing errors.
This is legacy behaviour - all vixie-cron releases have behaved this
The next release (vixie-cron-4.1-20) will emit error messages for
job parse errors to /var/log/cron .
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.
*** Bug 163341 has been marked as a duplicate of this bug. ***
Thanks for adding the bad lines reporting, but it isn't working for me yet.
$ rpm -q vixie-cron
$ tail -1 /etc/crontab
cron sees the change, but doesn't log a parse error.
Oct 24 23:36:01 localhost crond: (*system*) RELOAD (/etc/crontab)
Here is the bad line:
$ tail -1 /etc/crontab
I can't see the error reporting in vixie-cron 4.1-44.
echo "fdioufsduigioju" > /etc/crontab
shows no errors in /var/log/messages
Me too. I work on better log files in at/crond. For now I can't say in which
version will be everything allright.
This is still broken, and annoying too, because cron seems to treat the macro
times @hourly, @daily differently from "real" times.
>> /etc/crontab(In reply to comment #7)
> echo "fdioufsduigioju" > /etc/crontab
echo "fdioufsduigioju" >> /etc/crontab
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.?
(In reply to comment #11)
> Comment#10: you can't edit crontab this way, beacuse it doesn't install the
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).
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.
(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.
@daily someuser /bin/date
> # 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
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
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.
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
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:
Each line has five time and date fields, followed by a user name if
this is the system crontab file, followed by a command.
These special time specification "nicknames" are supported, which
replace the 5 initial time and date fields, and are prefixed by the ’@’
As for reloading cron:
"cron(8) examines cron entries once every minute."
-- man 5 crontab
I try answer all your question. I see only problem in manual page, which I'll
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
can't be controlled at all.
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.
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.
This is not fixed.
Try this, from comment #7 above:
echo "fdioufsduigioju" >> /etc/crontab
Do you get an error message? Where?
Nov 27 13:15:55 neco crond: (CRON) STARTUP (4.3)
Nov 27 13:15:55 neco crond: CRON: error in (/etc/crontab) problem is (bad
Nov 27 13:16:01 neco CROND: (root) CMD (id -a > /var/tmp/out.txt)
Nov 27 13:16:01 neco CROND: (root) CMD (touch /tmp/root)
Nov 27 13:16:01 neco CROND: (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.
> 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.
In this case you should say precisely, what I have to fix.
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.
crontab should complain whenever the system crontab does not match one of these
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.