Cron jobs show up in GNOME Scheduler but don't execute

Gnome Scheduler is just a pretty front-end for at and crontab. And in default Ubuntu, cron mostly runs anacron which is responsible for running periodic tasks on machines that may not be on when the task is supposed to fire.

Things to check are:

• is cron running? ps -C cron
• is cron configured? cat /etc/crontab
• is cron calling anacron from /etc/crontab?
• is anacron installed? ls /usr/sbin/anacron
• is cron or anacron logging any messages at all? grep CRON /var/log/syslog

For the last step, logrotate may have archived older syslogs so if grep gives no result try

(cat /var/log/syslog.[0-9] ; zcat /var/log/syslog.*.gz) | grep CRON

My guess is that gnome-scheduler is setting up jobs with the wrong permissions (probably as you and not a superuser) and therefore the complaints will appear in the syslogs.

response to update

Given the shell prompt in your crontab -l example, you almost certainly listed bakhtiyor's per user crontab which may not have the permissions to run your (somewhat opaque) jobs.

The syslog entries will show if the jobs are being run at all, and if so, if the jobs complain.

Based on your log entries, it looks like your jobs did not run recently.

You should also check the archived cron logs, because it might have turned over since they last run.

To debug this further I would add this job, using crontab -e

*/5 * * * * echo hello

and see if that sends you mail, and whether it appears in the log file.

update: If it's appearing in the log file but not sending you mail, then you might need to either install a mail agent to see the output from your backup jobs, or run them with output redirected into a log file. For instance, you could use crontab -e to change one line to

0 15 * * * nice -n 19 /usr/bin/backintime --backup-job >> ~/log/backup.log 2>&1

you will need to create the ~/log directory.

This solution worked for me: https://answers.launchpad.net/backintime/+question/90513

My job configuration was saved under my user and not root because I was using sudo backintime-gnome and not gksu backintime-gnome.

sudo will not change HOME environ which causes problems:

$ sudo env | grep ^HOME
HOME=/home/user
$ gksu env | grep ^HOME
HOME=/root

I had the same issue and solved it by adding my username to the crontab group.

1. Edit /etc/group
2. Locate the line containing crontab (there should be only 1 line)
3. Add you username at the end (if other users are on the line, separate with a comma)
4. reboot

I had a similar problem which gave me quite a runaround. Assuming cron, crontab and anacron are healthy, the key symptom is that the task runs correctly if invoked using gnome-schedule's "run now" button, but does not run as scheduled once left alone.

This turns out to be mostly a graphical environment issue. My recommendation is to create a wrapper for the task script, e.g. "task-wrapper":

#!/bin/sh
gnome-terminal -x /home/username/task

Make sure the task-wrapper file is executable, and create the task in gnome-schedule as an X application. Alternately, write it like this:

#!/bin/sh
export DISPLAY=:0
gnome-terminal -x /home/username/task

The /home/username/task script will now run in a console window which will close upon completion. My scripts typically require sudo authentication, so I start the "task" script like this:

#!/bin/sh
set -e
MESSAGE="The task script wants to ..."
gksudo --message "$MESSAGE" cd /whatever

The cd command is inoccuous, the MESSAGE explains what the script is requesting authorization for, and 'set -e' ensures the script aborts if the user hits 'Cancel'. The remainder of the script can use simple 'sudo' calls which will succeed unless a lot of time elapses between commands.

Under Ubuntu 12.04, crontab group membership doesn't seem to be required.