Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I used crontab -e to add the following line to my crontab:

* * * * * echo hi >> /home/myusername/test

Yet, I don't see that the test file is written to. Is this a permission problem, or is crontab not working correctly?

I see that the cron process is running. How can I debug this?

Edit - Ask Ubuntu has a nice question about crontab, unfortunately that still doesn't help me.

Edit 2 - Hmm, it seems my test file has 214 lines, which means for the last 214 minutes it has been written to every minute. I'm not sure what was the problem, but it's evidently gone.

share|improve this question
add comment

6 Answers

up vote 13 down vote accepted

There are implementations of cron (not all of them, and I don't remember which offhand, but I've encountered one under Linux) that check for updated crontab files every minute on the minute, and do not consider new entries until the next minute. Therefore, a crontab can take up to two minutes to fire up for the first time. This may be what you observed.

share|improve this answer
1  
I'd guess Solaris, or maybe early Solaris. I have a habit of making the cron entry run 3-5 minutes in the future when I test a script from a crontab entry, because I used to get fooled by this behavior all the time. –  Bruce Ediger Mar 17 '11 at 22:19
    
fcron does this too. –  phunehehe Mar 18 '11 at 1:36
add comment

Have you added an empty line after your cronjob?

share|improve this answer
    
There is an empty line after my cronjob. –  ripper234 Mar 17 '11 at 18:13
2  
Not an empty line, but a newline at the end of the last line. A text file is supposed to consist of a sequence of lines, each terminated by a newline, so any non-empty text file ends with a newline character. Some utilities don't process anything after the last newline in a file. –  Gilles Mar 17 '11 at 19:56
    
This is question of terms, "newline character" means "after this character start new line of text". So 0 bytes between last newline and EOF also may be considered as an empty line ("line which contains 0 characters") –  gelraen Mar 17 '11 at 20:29
add comment

I had the same problem - a working crontab suddenly stopped after I added a new entry at the end. It turned out that I had forgotten to put a newline after that last line.

I found out by issuing the command

cat /var/log/syslog | grep crontab

and the output showed the problem:

Jul  2 08:16:01 shiva cron[1254]: (*system*) RELOAD (/etc/crontab)
Jul  2 08:16:01 shiva cron[1254]: (*system*) ERROR (Missing newline before EOF, this crontab file will be ignored)

Adding the newline and saving fixed the problem.

share|improve this answer
add comment

Sounds like this is fixed. Next time, try logging the STDERR as well. The following will only log to STDOUT, not STDERR:

* * * * * echo hi >> /home/myusername/test

Try to make sure there is an explicit clause for STDERR as well. Otherwise, STDERR may be sent via email to the user (assuming that email is working) or may go nowhere at all, depending on how Cron is configured.

* * * * * echo hi >> /home/myusername/test 2> /home/myusername/test.stderr

My preference is to send cronjob output to syslog. That way I am taking advantage of any existing syslog infrastructure (centralized syslogs, Splunk, log rotation already supported, it's easy to compare messages in /var/log/messages & /var/log/cronjob, etc), and I'm not spamming the sysadmins (me) with unnecessary emails.

* * * * * echo hi >> /home/myusername/test 2>&1 | /usr/bin/logger -t mycronjob
share|improve this answer
add comment

Your cron line works fine on my computer when I change myusernae to phunehehe. There are several ways to find out what's wrong with your system.

Cron usually send mail to the user when there is something wrong. If you see the message "You have mail" use a mail client to check your inbox. Or, check in your home directory, there may be a file named dead.letter there.

You can check /var/log/ for entries relating to cron. On my computer the log file is at /var/log/cron/current (requires root access).

If you have root access, you can stop the cron daemon and start it in debug mode. For example I would use (change fcron to the name of your daemon):

killall fcron
fcron --foreground --debug
share|improve this answer
    
How do I find out the name of my daemon? –  ripper234 Mar 17 '11 at 17:05
    
@ripper234 use ps -ef | grep cron and you should see a line for your cron. Check the man page of the cron to see the flag for debug. It's likely that you are using Vixie Cron, in that case the debug flag is -x. Kill the cron process and start it again with the additional flag. –  phunehehe Mar 18 '11 at 1:34
add comment

Most likely, when cron fails, it generates an email to the user id of the cron job on that computer. If you don't have an MTA working on your computer, or you aren't reading or forwarding that mail somewhere else, you won't see that message, even if the MTA is working.

A good way to get your crontab's errors via mail is to make your crontab look like this:

MAILTO="myemail@example.com"
* * * * * echo hi >> /home/myusernae/test

Obviously, use your email address rather than myemail@example.com. This tells cron to send errors to your email address rather than the local account. In particular, this is useful if you have a root crontab (or crontab fragment in /etc/cron.d) that you want to just send output to you, you can avoid spamming root's mailbox or root's forwarding address.

share|improve this answer
    
I don't know if the system has an SMTP/outgoing mail server configured. Odds are that it doesn't. –  ripper234 Mar 17 '11 at 16:44
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.