Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

A quick overview: I have a script that will daily backup my source code repository from SVN into a tarball for that day. I have tested the script and it works very well as long as I run it as sudo, because of ownership of the output directory.

So the issue is that I want to run this daily, so I put a link to it in the /etc/cron.daily directory. Here are the contents of the directory.

thom@spenser:/etc/cron.daily$ ls -l
total 60
-rwxr-xr-x 1 root root   189 2011-09-14 02:21 apport
-rwxr-xr-x 1 root root 15535 2011-10-06 11:30 apt
-rwxr-xr-x 1 root root   314 2011-08-08 16:57 aptitude
lrwxrwxrwx 1 root root    24 2012-02-28 11:05 backup -> /usr/local/bin/backup.sh
-rwxr-xr-x 1 root root   502 2011-06-08 11:48 bsdmainutils
-rwxr-xr-x 1 root root   256 2011-10-06 04:04 dpkg
-rwxr-xr-x 1 root root   372 2011-10-04 16:50 logrotate
-rwxr-xr-x 1 root root  1353 2011-07-27 07:17 man-db
-rwxr-xr-x 1 root root   606 2011-08-17 09:16 mlocate
-rwxr-xr-x 1 root root   249 2011-06-24 05:36 passwd
-rwxr-xr-x 1 root root  2417 2011-07-01 17:25 popularity-contest
-rwxr-xr-x 1 root root   383 2011-09-30 15:09 samba
-rwxr-xr-x 1 root root  3594 2011-09-19 20:07 standard
thom@spenser:/etc/cron.daily$ 

The problem is that it simply never runs. Here is the permissions for that script:

thom@spenser:/etc/cron.daily$ ls -l /usr/local/bin/backup.sh 
-rwxr-xr-x 1 root root 260 2012-02-28 11:03 /usr/local/bin/backup.sh

Ideas?

share|improve this question
1  
If possible, please consider closing some of your other open questions by selecting the best answer (if they have one). We need users to maintain their questions so that the site can be an effective tool for the next person with your problems. For more details on best practices consider reading the FAQ on asking questions. –  Bruno Pereira Mar 12 '12 at 10:31

3 Answers 3

Tried this

run-parts --test /etc/cron.daily

Found that my file update.ubuntu did not come up. Also noticed that my file had an extension (has dot in it).

Steps to fix this.

  1. Renamed my update.ubuntu to update-ubuntu
  2. Now again run-parts --test /etc/cron.daily, this time my file came up!
share|improve this answer
    
Yeah, this fixed it for me. It doesn't like dots in the filename, renaming my file from myscript.sh to myscript worked for me. –  Matt Parkins Jun 10 '13 at 9:03
    
This needs to be higher. I had my script saved as the traditional "backup.sh". Removing the ".sh" part solved it. Thanks a ton! –  David Sep 23 '13 at 16:32
    
Thanks! The guy/gal who decided to implicitly remove .sh files from the daily cron should be shamed! –  Sylvain Feb 27 at 9:45

Could be one of several things:

Roots path:

Depending on the commands being run, you may need to expand the root users PATH variable by putting the following line at the top of their crontab file:

PATH=/usr/sbin:/usr/bin:/sbin:/bin

src: https://help.ubuntu.com/community/CronHowto

Or just use full paths to each command in your script: /bin/ls instead of ls for example. (which ls at command line for paths).

There is a strange bug about dots in the filename reported here. Might extend to the file you are linking to, although this seems unlikely.

Are you saving the output from the backup file? Put something like this on the first line, to help determine if it is not running at all or running but failing at some point.

/bin/echo "Attempting to run backup" >> /path-to-home/backup.log

Alternatively try adding the script to the crontab file directly:

sudo -i
crontab -e
[add the next line to the file, then save and exit]
33 15 * * * /usr/local/bin/backup.sh

will run at 15:30 every day if the machine is on. use * * * * * while testing to run once a minute until you get it working.

share|improve this answer
1  
Using absolute paths in scripts is discouraged. If you don't know what PATH is, set it yourself in the script. See Reasons why crontab does not work –  geirha Mar 12 '12 at 12:37
    
Useful link, thanks. The given reason not to use full paths is portability. Fair enough. Another reasonable solution is to define the commands you are using at the start of the script, along with other configurations: LS=/bin/ls; SRC_DIR=/home/joe/src. Then use $LS $SRC_DIR. Keeps everything defined at the top and in one place. –  Sean Mar 12 '12 at 12:50
    
I find that to reduce readability, and you have to go over every COMMAND=/path/to/command for every new system it should run on. On one system, all the commands you need could be in /usr/bin, on another some are in /bin, others in /usr/bin. Just having both /usr/bin and /bin in PATH makes that a non-issue. On a side note, variable names should be lowercase, else you risk overriding special shell variables or environment variables. –  geirha Mar 12 '12 at 14:54
    
re: upper case variable names. I have always done that without much thought, due to the first scripts I saw doing it. But you are right, there is no upside and a chance of downside. Thanks for pointing this out, breaking this habit now. –  Sean Mar 14 '12 at 10:30

Grep your syslog for messages like;

crond: (*system*) BAD FILE MODE

the files need to be restricted to (is sufficient) at 644):

chmod 0644 /etc/cron.d/my_crontab
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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