|Summary:||Poor error handling for bad lines in system crontab|
|Product:||[Fedora] Fedora||Reporter:||Need Real Name <lsof>|
|Component:||cronie||Assignee:||Marcela Mašláňová <mmaslano>|
|Status:||CLOSED RAWHIDE||QA Contact:||Brock Organ <borgan>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2008-01-31 11:27:38 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Need Real Name 2004-11-03 10:34:37 UTC
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 10:53:27 UTC
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 15:04:09 UTC
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 16:37:32 UTC
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 07:53:33 UTC
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 13:55:07 UTC
*** Bug 163341 has been marked as a duplicate of this bug. ***
Comment 6 Need Real Name 2005-10-24 21:35:31 UTC
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: (*system*) RELOAD (/etc/crontab) Here is the bad line: $ tail -1 /etc/crontab esgsdgsdgdsgsdgdsgds
Comment 7 Need Real Name 2006-01-25 10:23:07 UTC
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 14:10:04 UTC
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 20:01:24 UTC
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 20:04:23 UTC
>> /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 11:29:03 UTC
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 13:59:39 UTC
(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 14:18:17 UTC
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 16:55:11 UTC
(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 13:04:06 UTC
> # 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 16:52:03 UTC
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 17:34:45 UTC
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 17:48:30 UTC
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 07:40:38 UTC
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 17:32:10 UTC
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 09:36:10 UTC
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 20:28:37 UTC
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 12:25:14 UTC
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 minute) 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.
Comment 24 Need Real Name 2007-11-27 18:29:34 UTC
> 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 08:16:50 UTC
In this case you should say precisely, what I have to fix.
Comment 26 Need Real Name 2007-11-28 19:56:08 UTC
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 08:29:09 UTC
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.