Как посмотреть ошибки crontab

As others have pointed out, cron will email you the output of any program it runs (if there is any output). So, if you don’t get any output, there are basically three possibilities:

1. crond could not even start a shell for running the program or sending email
2. crond had troubles mailing the output, or the mail was lost.
3. the program did not produce any output (including error messages)

Case 1. is very unlikely, but something should have been written in the cron logs. Cron has an own reserved syslog facility, so you should have a look into /etc/syslog.conf (or the equivalent file in your distro) to see where messages of facility cron are sent. Popular destinations include /var/log/cron, /var/log/messages and /var/log/syslog.

In case 2., you should inspect the mailer daemon logs: messages from the Cron daemon usually appear as from root@yourhost. You can use a MAILTO=... line in the crontab file to have cron send email to a specific address, which should make it easier to grep the mailer daemon logs. For instance:

MAILTO=my.offsite.email@example.org
00 15 * * *  echo "Just testing if crond sends email"

In case 3., you can test if the program was actually run by appending another command whose effect you can easily check: for instance,

00 15 * * * /a/command; touch /tmp/a_command_has_run

so you can check if crond has actually run something by looking at
the mtime of /tmp/a_command_has_run.

As a Linux user, you are probably already familiar with crontab. You can automate tasks by running commands and scripts at a predefined schedule. Want to automatically take backups? Crontab is your friend.

I am not going into the usage of crontab here. My focus is on showing you the different ways to check crontab logs.

It helps investigate whether your cronjobs ran as scheduled or not.

Method 1: Check the syslog for crontab logs

As per the Linux directory hierarchy, the /var/log directory in Linux stores logs from the system, services, and running applications.

While the cron logs are also in this directory, there is no standard file for these logs. Different distributions keep them in different files.

For Debian-based distributions, the file /var/log/syslog contains the logs from the cron job execution and should be consulted in case your cron jobs are not working:

cat /var/log/syslog | grep -w 'cron’

You will see all cron jobs listed on your terminal when the above command is run. The grep command will filter the cron related messages apart from the rest.

For RedHat-based distros, the cron logs have dedicated file /var/log/cron.

In both cases, you will probably need to specify the sudo keyword or use the root account to access the logs.

Method 2: Use a custom log file (recommended)

Using a separate custom file for logging cron jobs is a recommended practice.

For this, you can configure ‘rsyslog’ to forward cron logs. Rsyslog is a Linux service that has features similar to Syslog logging.

Simply create a file cron.log under the directory /etc/rsyslog.d:

touch /var/log/cron.log

Now open the file /etc/rsyslog.d/50-default.conf for editing:

nano /etc/rsyslog.d/50-default.conf 

and locate the line starting with #cron.* and remove the # at the start of the line.

To make the changes work, save and close this file and finally restart the rsyslog service and check its status:

sudo systemctl restart rsyslog

sudo systemctl status rsyslog

The status of the service should be highlighted as active (running).

Now, whenever you need to access the crontab logs, just read the content of this log file:

less /var/log/cron.log

Method 3: Use dedicated services like Cronitor monitor cron jobs

Cronitor is a service that can be deployed to monitor any type of cron job.

Many of the cron versions will start logging when the scheduled job executes or if there are any problems with the crontab. However, the output from the cron job or its exit status is not logged.

Here Cronitor comes in handy and works perfectly. It is a complete solution for all your crontab needs. It captures logs, metrics, and status from all the jobs and creates instant alerts for crashed or failed to start cron jobs.

You can see all this through a web-based interface.

For Cronitor or CronitorCLI installed on Kubernetes, logs can be captured for as high as 100MB for a single execution. Here, you can find the detailed installation steps on Linux for CronitorCLI.

Other monitoring tools and services like Better Uptime also provide the feature to monitor the cron jobs automatically.

Conclusion

System log files are very crucial for troubleshooting and diagnosing system-related issues, cron logs are thus no exception for this.

The Syslog keeps the logs related to crontab however, having a dedicated log file for cron is recommended. A web-based service like Cronitor, Better Uptime, and Uptime Robot also helps.

The syntax for the crontab entry looks correct. Indeed, if you edit your crontab using «crontab -e» (as you should), you’ll get an error if you specify a syntactically invalid crontab entry anyway.

1. Firstly, does /path_to_my_php_script/info.php run correctly from the command-line?

2. If so, does it also run correctly like this?:

   /bin/sh -c "(export PATH=/usr/bin:/bin; /path_to_my_php_script/info.php </dev/null)"
   

3. If that works, does it work like this?

   /bin/sh -c "(export PATH=/usr/bin:/bin; /path_to_my_php_script/info.php </dev/null >/dev/null 2>&1)"
   

Step (3) is similar to how cron will run your program (as documented in «man 5 cron».

The most likely problem you’re having is that the PATH cron is using to run your program is too restrictive. Therefore, you may wish to add something like the following to the top of your crontab entry (you’ll need to add in whatever directories your script will need):

PATH=~/bin:/usr/bin/:/bin

Also note that cron will by default use /bin/sh, not bash. If you need bash, also add this to the start of your crontab file:

SHELL=/bin/bash

Note that both those changes will affect all the crontab entries. If you just want to modify these values for your info.php program, you could do something like this:

*/2 * * * * /bin/bash -c ". ~/.bashrc; /path_to_my_php_script/info.php"

It’s also worth mentioning that on a system configured for «mail» (in other words a system which has an MTA configured [sendmail/postfix/etc]), all output from crontab programs is sent to you via email automatically. A default Ubuntu desktop system won’t have local mail configured, but if you’re working on a server you can just type «mail» in a terminal to see all those cron mails. This also applies to the «at» command.

Cron can generate logs, which are very useful in troubleshooting your cron jobs.
In this quick tutorial, we will take a look at cron logs – how to find them and
how to read them.

Where are cron logs stored?

By default, all cron logs are stored in the main system log which is located in
/var/log/syslog on Ubuntu and Debian systems and in /var/log/cron on CentOS.

You can filter cron logs in the system log by running the grep command.

cat /var/log/syslog | grep cron

This applies to Ubuntu and Debian. On CentOS, simply replace the system log
directory to /var/log/cron and you are good to go.

How to set up cron.log file?

Another way you can monitor cron logs is to set up separate log file especially
for cron logs.

To do this, open the /etc/rsyslog.d/50-default.conf configuration file in the
nano editor using the following command:

sudo nano /etc/rsyslog.d/50-default.conf

This will open the configuration file for editing. In this file, uncomment the
highlighted line to enable logging cron logs into the /var/log/cron.log file.

Output:
#  Default rules for rsyslog.
#
#  For more information see rsyslog.conf(5) and /etc/rsyslog.conf

#
# First some standard log files.  Log by facility.
#
auth,authpriv.*                 /var/log/auth.log
*.*;auth,authpriv.none          -/var/log/syslog
#cron.*                         /var/log/cron.log
#daemon.*                       -/var/log/daemon.log
kern.*                          -/var/log/kern.log
#lpr.*                          -/var/log/lpr.log
mail.*                          -/var/log/mail.log
#user.*                         -/var/log/user.log

#
# Logging for the mail system.  Split it up so that
# it is easy to write scripts to parse these files.
#
#mail.info                      -/var/log/mail.info
#mail.warn                      -/var/log/mail.warn
mail.err                        /var/log/mail.err

#
# Some "catch-all" log files.

...

The highlighted line should look like this:

We are not done yet. Now we need to create the /var/log/cron.log file. To do
this, simply run the following command:

sudo nano /var/log/cron.log

Save the empty file and exit. Then restart the rsyslog service:

sudo systemctl restart rsyslog

At this point, all cron logs are stored in the /var/log/cron.log file.

How to watch cron logs in real-time?

To view cron logs in real-time, create watchcron file using the following
command:

Add the following line in the file. Then save and exit the file.

watch -n 10 tail -n 15 /var/log/cron.log

This will refresh the logs event page after 10 seconds and displays the last 15
events on the page.

Add the executable permission to the newly created watchcron file:

And finally, copy this file in /usr/sbin location using the following command:

sudo cp watchcron /usr/sbin

Now to watch cron log in real-time, simply type watchcron in the terminal and
hit enter.

Explore more