LinuxQuestions.org - Backup script won't run in cron job. Why?

- Linux - General (https://www.linuxquestions.org/questions/linux-general-1/)

- - Backup script won't run in cron job. Why? (https://www.linuxquestions.org/questions/linux-general-1/backup-script-wont-run-in-cron-job-why-502661/)

Backup script won't run in cron job. Why?

I have a simple backup script that I put in /etc/cron.daily. It won't run! However, it runs fine when I do it manually.

Code:

sudo ./backup.cron

It is copying from the hard drive to an external hard drive (VFAT, ROOT ownership).

here is the backup script

Code:

#!/bin/sh

# full and incremental backup script

# created 07 February 2000

# Based on a script by Daniel O'Callaghan <danny@freebsd.org>

# and modified by Gerhard Mourani <gmourani@videotron.ca>



#Change the 5 variables below to fit your computer/backup



COMPUTER=server                                  # name of this computer

DIRECTORIES=/projects                            # directoris to backup

BACKUPDIR=/media/usbdisk                              # where to store the backups

TIMEDIR=/media/usbdisk/last-full                      # where to store time of full backup

TAR=/bin/tar                                            # name and locaction of tar



#You should not have to change anything below here



PATH=/usr/local/bin:/usr/bin:/bin

DOW=`date +%a`                              # Day of the week e.g. Mon

DOM=`date +%d`                              # Date of the Month e.g. 27

DM=`date +%d%b`                    # Date and Month e.g. 27Sep



# On the 1st of the month a permanet full backup is made

# Every Sunday a full backup is made - overwriting last Sundays backup

# The rest of the time an incremental backup is made. Each incremental

# backup overwrites last weeks incremental backup of the same name.

#

# if NEWER = "", then tar backs up all files in the directories

# otherwise it backs up files newer than the NEWER date. NEWER

# gets it date from the file written every Sunday.





# Monthly full backup

if [ $DOM = "01" ]; then

        NEWER=""

        $TAR $NEWER -cf $BACKUPDIR/$COMPUTER-$DM.tar $DIRECTORIES

fi



# Weekly full backup

if [ $DOW = "Sun" ]; then

        NEWER=""

        NOW=`date +%d-%b`



        # Update full backup date

        echo $NOW > $TIMEDIR/$COMPUTER-full-date

        $TAR $NEWER -cf $BACKUPDIR/$COMPUTER-$DOW.tar $DIRECTORIES



# Make incremental backup - overwrite last weeks

else



        # Get date of last full backup

        NEWER="--newer `cat $TIMEDIR/$COMPUTER-full-date`"

        $TAR $NEWER -cf $BACKUPDIR/$COMPUTER-$DOW.tar $DIRECTORIES

fi

So any ideas why it runs when I do it manually, but not automatically by cron.daily? I have tested that my other cron jobs are running daily by putting simple scripts in the /etc/cron.daily, so I don't know why this backup script won't run by itself.

Check the cron log (usually /var/log/cron) for errors.

When something runs from the commandline but not from cron, first, suspect environment. Then look into environment problems. Finally, investigate what might be different in the environment!

Joking aside, it's almost always a command you're calling based on something in your PATH, but that PATH environment is not the same under cron. So the command is not found. Maybe it's not even finding the most basic thing - your backup script itself! Or it could be some other environment variable that is missing. Cron gives you a very truncated environment to work with. Occassionally you'll run into a problem where your commandline shell is not the same shell cron gives you by default. I haven't seen this so much under Linux, but under Solaris you can run into issues with /bin/ksh as you commandline and plain old /bin/sh being handed to you by cron.

Quote:

Originally Posted by macemoneta

Check the cron log (usually /var/log/cron) for errors.

No such cron log. :(

Quote:

Originally Posted by haertig

That's what I suspect. I think there is something in the environment that is not being recognized. I will try copying my current environment settings into the script. Should I also change the script to a #!/bin/bash ????

What directory is your script in? Try adding that directory to the line:

PATH=/usr/local/bin:/usr/bin:/bin

Also I vaguely remember reading that CRON doesn't like files with an extension. Try changing the file name to something like backup_cron.

Keith

Quote:

Originally Posted by Micro420

No such cron log. :(

I find my cron output in /var/log/syslog

Quote:

Originally Posted by matthewg42

I find my cron output in /var/log/syslog

Wow, this is weird! This is what I get:

Code:

 sudo cat syslog.0 | grep cron.daily

Nov 17 07:35:57 ubuntu anacron[27202]: Job `cron.daily' terminated

Nov 18 06:25:01 ubuntu /USR/SBIN/CRON[28634]: (root) CMD (test -x /usr/sbin/anacron || run-parts --report /etc/cron.daily)

Nov 18 07:30:01 ubuntu anacron[28700]: Will run job `cron.daily' in 5 min.

Nov 18 07:35:01 ubuntu anacron[28700]: Job `cron.daily' started

Nov 18 07:35:01 ubuntu anacron[28705]: Updated timestamp for job `cron.daily' to 2006-11-18

In other words, everything seems to be running fine with cron, but there is something not right in the backup script, even though I am able to manually run it. Any other ideas??

How are you making cron execute the script? Do you have a copy of the script in /etc/cron.daily/, or did you add an entry in the user crontab for some user (e.g. root).

If you entered a line into a user crontab, can you paste that line here?

In either case if a program called by cron produces output, that output should be mailed to your admin user, so having local mail delivery working is useful if you've not set that up already. (look in /var/mail to see if there are mail files which you aren't picking up. You'll be able to read them just with less (although it's ugly), or you can point your mail client to the files there and say it's the mbox format - this should split the messages up and format them a little better).

Last idea, umm, if you launch from a crontab for a user, try appending "> /tmp/my.log 2>&1", wait for the command to execute and then see what's in this logfile, /tmp/my.log

You guys won't believe this, but I found the problem. The problem was the filename I gave the script. I called it /etc/cron.daily/backup.cron. I decided to just rename it to /etc/cron.daily/backup and now my daily backups are happening. I don't see why the filename would be the problem, but I guess it is. Very odd! Now my next task is learning how to rsync the data to another remote server on a daily basis.

Quote:

Originally Posted by keithweddell

Told you.

Keith

Most awesome! Couldn't have figured it without your help! I can't believe it was just a little simple filename change that made the difference. Bleh! :p

I never knew cron had a preference for some names. [checks manual page]

Quote:

Originally Posted by cron_manual_page

...Such files should be named after the package that supplies them. Files must conform to the same naming convention as used by run-parts(8): they must consist solely of upper- and lower-case letters, digits, underscores, and hyphens.

So there we are. Far out. I have to say I was skeptical that a filename change would make a difference (not enough to say so, but heh). I stand corrected. Nice one.

Yup, learn something new every day. Thanks! :)

Glad I could help. I think I picked it up from a random comment on the Ubuntu forums.

Keith

Quote:

Originally Posted by macemoneta

Yup, learn something new every day. Thanks! :)

Hmmm. I'll have to try this on my Debian box. I don't have many cronjobs there, but they all DON'T have extensions. Not by plan, but by coincidence.

I know this cron limitation/anomoly does not apply to Solaris. I just checked my crontabs on a few of those servers and ALL of my jobs have extensions. Typically *.sh or *.pl

Interesting to note that Linux might handle things differently. I must say, I'm surprized by this. What possible reason would there be?