I'm having a bit of a problem with cronjobs for backups.

I've set up the following in sudo crontab -e (not under personal account):

0 1 * * * /backups/dobackup

/backups/dobackup contains this:

touch ITRAN
tar -cvpjf /backups/$(date +%d.%m.%Y)_backup.tar.bz2  --exclude=/backups --exclude=/proc --exclude=/lost+found --exclude=/sys --exclude=/mnt --exclude=/media --exclude=/dev /

The backup file is created, but the file ITRAN is not. Also, the backup file is vastly smaller than expected:

-rw-r--r--  1 rjrudman root      371620259 2012-06-21 12:39 21.06.2012_backup.tar.bz2
-rw-r--r--  1 rjrudman root     1023211449 2012-06-22 18:00 22.06.2012_backup.tar.bz2
-rw-r--r--  1 rjrudman root        1512785 2012-06-23 01:00 23.06.2012_backup.tar.bz2
-rw-r--r--  1 rjrudman root     1023272455 2012-06-24 22:41 24.06.2012_backup.tar.bz2
-rw-r--r--  1 rjrudman root        1514027 2012-06-25 01:00 25.06.2012_backup.tar.bz2

The backups with much larger file sizes are created by manually running sudo /backups/dobackup. It seems the cronjob is failing at some point.. but I have no idea how to debug this issue or where to start.

Any ideas? Running ubuntu 10.04

  • 1
    You can always redirect stdout & stderr to find out if tar fails, as well as the value of pwd to see where ITRAN is created. – mlt Jun 24 '12 at 23:57
  • @mlt Cheers, I'll give it a go and have a look next time it runs – Rob Jun 25 '12 at 0:20
  • BTW, instead of using crontab -e you could place a file in /etc/cron.d/, the file format is slightly different and allows you to set the username you want. See the existing files in that directory for examples. – Zoredache Jun 25 '12 at 1:04

If you want to find out why it's failing, try logging the output of your backup script:

0 1 * * * /backups/dobackup >& /root/dobackup.log
  • Cheers - I've set that up - is there any way to trigger a cronjob immediately? Other than setting up a new one a few minutes from now? – Rob Jun 25 '12 at 0:31
  • 1
    Simple answer is no: just schedule one to execute in the next minute. But nothing would stop you from creating a fairly simple program to allow arbitrary scripts to be executed by cron. You'd run it as * * * * *, and have it poll a control queue file for changes every second until 60 seconds had elapsed, then exit. If something showed up in the queue it would be executed and then removed from the queue (you'd need file locking to prevent multiple executions). You would use this same program (with different arguments) to add entries to the queue. That's what I'd do anyway... =) – paddy Jun 25 '12 at 2:23

Crontab environment is not the same environment as bash terminal. You need to program commands for crontab seperateley.

  • Is there any way I can emulate the crontab environment and run it immediately for testing? – Rob Jun 25 '12 at 0:13
  • 1
    @Rob You should use full paths. Instead of touch and tar use the full path, like /usr/bin/touch. To find the location of the program, use whereis touch and same for tar. – Devator Jun 25 '12 at 0:48

One thing I have learned is to figure out what the cron environment has access to.

This may not be a solution but it could open your eyes to this issue in the future.

Have cron execute this command:

* * * * *  set > /temp/text/file

Take a look at it and compare it to that of a normal bash shell.

Vastly different and it will cause unseen problems

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.