Troubleshooting custom cron scripts
I often have trouble when creating my own scripts to be run by cron on Linux servers. On most of the servers that I administer, I use a homegrown backup script (based on these excellent instructions) that I place in /etc/cron.daily. After upgrading a server to Debian Etch recently I found that my backup script, named backup-script.sh, was no longer working.
After stumbling around in the dark for a while, I found a useful tool to use when trying to troubleshoot cron jobs:
run-parts --list /etc/cron.daily
This command lists the valid scripts in a directory. I noticed that backup-script.sh was the only script in the directory that was missing from the list. After checking that ownership and permissions on all of the scripts were the same (using ls -l), it clicked that the only difference between my backup script and the other valid scripts was that the backup script's name ended with the extension .sh. After removing that, I used run-parts --list again and my backup script was now included in the list of valid files. Sweet! And a definite relief given how important reliable backups are!


Comments
The run-parts rules for what script names have to be used are pretty strict.
From run-parts(8):
These strict limitations actually come in handy when you might use a text editor which drops backup files with arbitrarily-named suffixes into the directory (e.g. if you edit the file foo with emacs, it will leave foo~ lying around). you don't want those files being run automatically!
Hey, good to know the details behind the functionality, Daniel! Especially given that text editor goofiness. Though wouldn't
foo~not be run because it includes a tilde, which isn't an allowed character?ahhhh... thank you! i recently had a hard drive crash only to find out my daily script wasn't running. guess what? it ends in ".sh" -- argh! thanks much for this, been beating my head against the screen for days.
Post new comment