The above message was shown because the crontab file has permissions of 666 which is an insecure and invalid permission for crond.

If a job was unable to be run due to an error the log entry may appear as so.Įxample of a failed run: Nov 02 17:10:01 testbox CRON: (testuser) WRONG INODE INFO (crontabs/testuser) The above example shows the log message of a cronjob that was at least run by crond however not all messages may be successful. Nov 02 15:05:01 testbox CRON: (root) CMD (command -v debian-sa1 > /dev/null & debian-sa1 1 1) Once you have figured out which log file has the information you can simply search through the log file for the last run or a specific run of your cronjob.Įxample of a good run: # grep -i debian-sa1 syslog | tail -1 *.info mail.none authpriv.none cron.none /var/log/messages The syslog config file may be /etc/nf or /etc/nf depending on what syslog service you have installed.

Check the syslog configurationĪnother method of finding which log file to check is to simply check the syslog configuration as the syslog configuration will show either a specific line for cron or cron being defaulted to a general log file. On Ubuntu and Debian it is not so obvious the auth.log files contain the most lines from cron but these do not actually contain the lines we want. On the examples above the cron log file of Fedora is an obvious place to look not only because of the name but because it is the only log file with a significant amount of lines that contain the word cron. Ubuntu/Debian: # grep -ic cron /var/log/* | grep -v :0

In order to determine which log file contains the cron logs we can simply check the occurrence of the word cron in the log files within /var/log.įedora: # grep -ic cron /var/log/* | grep -v :0 The simplest way to validate that cron tried to run the job is to simply check the appropriate log file the log files however can be different from system to system. Finding the appropriate log fileĬrond unless configured otherwise will send a log message to syslog every time it invokes a scheduled job. Today I will show how to validate that cron at least attempted to run the command even if the output is nowhere to be found. Sometimes people will configure a cron to send the output of the script to a user via system mail or redirect the output to a file however not all crons are setup the same and many times they may be configured to send output to /dev/null hindering any ability to validate the job ran. Because cronjobs are time based sometimes it is necessary to validate that the job ran at the scheduled time. Cron is a time based scheduled task daemon that runs on most common Unix/Linux distributions.

Dd wrt cron reboot