30

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.

Community
  • 1
ripper234
  • 31,763

8 Answers8

30

Have you added an empty line after your cronjob?

Community
  • 1
gelraen
  • 6,737
  • There is an empty line after my cronjob. – ripper234 Mar 17 '11 at 18:13
  • 5
    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 'SO- stop being evil' Mar 17 '11 at 19:56
  • 1
    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
24

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.

Gilles 'SO- stop being evil'
  • 829,060
  • 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. –  Mar 17 '11 at 22:19
  • fcron does this too. – phunehehe Mar 18 '11 at 01:36
  • What if the "check" routine costs more than a few minute? There will be cronjobs that should be triggered during this lengthy "check" that were not triggered. – ospider Dec 16 '18 at 03:52
  • @ospider The check only takes a fraction of a second. – Gilles 'SO- stop being evil' Dec 16 '18 at 11:08
10

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.

uniomni
  • 101
4

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
Community
  • 1
Stefan Lasiewski
  • 19,754
  • 24
  • 70
  • 85
2

With me the problem was that the script was not executable. I had crontab -e setup like this

* * * * * /bin/my-script.sh

And the file myscript was not executable so I ran

chmod +x my-script.sh

Immediately I started seeing output as expected.

santiago arizti
  • 621
1

I would guess one reason for this may be that the /home/ directory is encrypted and when the user is logged out cron is unable to do anything in that directory.

see: https://stackoverflow.com/a/40354269/1279002

Community
  • 1
theINtoy
  • 129
1

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
Community
  • 1
phunehehe
  • 20,240
1

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.

jsbillings
  • 24,406