I have set up a cronjob for root user in ubuntu environment as follows by typing crontab -e
34 11 * * * sh /srv/www/live/CronJobs/daily.sh
0 08 * * 2 sh /srv/www/live/CronJobs/weekly.sh
0 08 1 * * sh /srv/www/live/CronJobs/monthly.sh
But the cronjob does not run. I have tried checking if the cronjob is running using pgrep cron
and that gives process id 3033. The shell script calls a python file and is used to send an email. Running the python file is ok. There's no error in it but the cron doesn't run. The daily.sh file has the following code in it.
python /srv/www/live/CronJobs/daily.py
python /srv/www/live/CronJobs/notification_email.py
python /srv/www/live/CronJobs/log_kpi.py
This question is related to
linux
cron
ubuntu-12.04
I've found another reason for user's crontab not running: the hostname is not present on the hosts file:
user@ubuntu:~$ cat /etc/hostname
ubuntu
Now the hosts file:
user@ubuntu:~$ cat /etc/hosts
127.0.0.1 localhost
# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts
This is on a Ubuntu 14.04.3 LTS, the way to fix it is adding the hostname to the hosts file so it resembles something like this:
user@ubuntu:~$ cat /etc/hosts
127.0.0.1 ubuntu localhost
# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts
To add another point, a file in /etc/cron.d must contain an empty new line at the end. This is likely related to the response by Luciano which specifies that:
The entire command portion of the line, up to a newline or a "%"
character, will be executed
It might also be a timezone problem.
Cron uses the local time.
Run the command timedatectl
to see the machine time and make sure that your crontab is in this same timezone.
I want to add 2 points that I learned:
Refs:
I experienced same problem where crons are not running. We fixed by changing permissions and owner by Crons made root owner as we had mentioned in crontab AND Cronjobs 644 permission given
For me, the solution was that the file cron was trying to run was in an encrypted directory, more specifcically a user diretory on /home/. Although the crontab was configured as root, because the script being run exisited in an encrypted user directory in /home/ cron could only read this directory when the user was actually logged in. To see if the directory is encrypted check if this directory exists:
/home/.ecryptfs/<yourusername>
if so then you have an encrypted home directory.
The fix for me was to move the script in to a non=encrypted directory and everythig worked fine.
Another reason crontab will fail: Special handling of the %
character.
From the man file:
The entire command portion of the line, up to a newline or a
"%" character, will be executed by /bin/sh or by the shell specified
in the SHELL variable of the cronfile. A "%" character in the
command, unless escaped with a backslash (\), will be changed into
newline characters, and all data after the first % will be sent to
the command as standard input.
In my particular case, I was using date --date="7 days ago" "+%Y-%m-%d"
to produce parameters to my script, and it was failing silently. I finally found out what was going on when I checked syslog
and saw my command was truncated at the %
symbol. You need to escape it like this:
date --date="7 days ago" "+\%Y-\%m-\%d"
See here for more details:
http://www.ducea.com/2008/11/12/using-the-character-in-crontab-entries/
Here's a checklist guide to debug not running cronjobs:
ps ax | grep cron
and look for cron.service cron start
or service cron restart
* * * * * /bin/echo "cron works" >> /tmp/file
/tmp
which does not currently exist should always be writable.2>&1
to include standard error as well as standard output, or separately output standard error to another file with 2>>/tmp/errors
/var/log/cron.log
or /var/log/messages
for errors.grep CRON /var/log/syslog
/var/log/cron
chmod +x /var/www/app/cron/do-stuff.php
30 1 * * * command > /dev/null 2>&1
>/dev/null 2>&1
altogether; or perhaps redirect to a file in a location where you have write access: >>cron.out 2>&1
will append standard output and standard error to cron.out
in the invoking user's home directory./etc/default/cron
EXTRA_OPTS="-L 2"
service cron restart
tail -f /var/log/syslog
to see the scripts executed/etc/rsyslog.d/50-default.conf
cron.crit /var/log/cron.log
sudo /etc/init.d/rsyslog reload
/var/log/cron.log
and look for detailed error output# Minute Hour Day of Month Month Day of Week User Command
# (0-59) (0-23) (1-31) (1-12 or Jan-Dec) (0-6 or Sun-Sat)
0 2 * * * root /usr/bin/find
This syntax is only correct for the root
user. Regular user crontab
syntax doesn't have the User field (regular users aren't allowed to run code as any other user);
# Minute Hour Day of Month Month Day of Week Command
# (0-59) (0-23) (1-31) (1-12 or Jan-Dec) (0-6 or Sun-Sat)
0 2 * * * /usr/bin/find
crontab -l
crontab -e
, for a specific user: crontab -e -u agentsmith
crontab -r
I found useful debugging information on an Ubuntu 16.04 server by running:
systemctl status cron.service
In my case I was kindly informed I had left a comment '#' off of a remark line:
Aug 18 19:12:01 is-feb19 cron[14307]: Error: bad minute; while reading /etc/crontab
Aug 18 19:12:01 is-feb19 cron[14307]: (*system*) ERROR (Syntax error, this crontab file will be ignored)
Sometimes the command that cron needs to run is in a directory where cron has no access, typically on systems where users' home directories' permissions are 700 and the command is in that directory.
Source: Stackoverflow.com