Bug 137962

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."

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
 way. 
 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. ***

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

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

Should be:

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
> 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).

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.
e.g.
# works:
@daily /bin/date
# fails:
@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

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.

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

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

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.

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[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.

> 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.
@weekly.

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

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.