run-parts scripts: a note about naming

by Juliet Kemp

run-parts is used (on Debian systems, anyway) to run the scripts in /etc/cron.daily (hourly, weekly, etc) on the appropriate schedule. I had trouble this week with a Perl script I'd dropped into /etc/cron.daily failing to run. Ran fine from the command line, of course. Odd.

Eventually it occurred to me, after a little light man page reading, to try run-parts --test /etc/cron.daily (which just prints the names of the scripts that would run). Script failed to show up. Most Odd.

I finally found the answer via Google, although a slightly less light reading of the man page would have helped. Scripts to be run by run-parts must adhere to a particular naming convention - in particular, no .xx endings. So my script.pl script wasn't being picked up due to that .pl ending. I renamed it to script and all was well.

(I'm not actually sure what the logic of this is; I'm assuming it's likely to be historical reasons. You can alter it with the --lsbsysinit option, if you prefer that. I know the .xx ending is by no means essential, but I prefer in general to have a quick visual of what language I've written a script in.)


7 Comments

Robert
2007-08-09 08:16:05
I would consider that a "bug" and not a "feature". Gack.
joshuadf
2007-08-09 10:55:00
The Fedora/Red Hat run-parts only filters out:

*[^~,]

*.{rpmsave,rpmorig,rpmnew,swp,cfsaved}

chromatic
2007-08-09 11:20:39
A quicker visual than head -n 1 script, you mean? ;)
Robert Loomans
2007-08-09 17:47:41
When dpkg updates config files (and /etc/cron.*/* are usually marked as config files) it will check if they have been changed.


If they have, and you tell it not to replace the file, it will drop the new file in as {file}.dpkg-dist.


If they have, and you tell it to replace the file, it will rename the old file as {file}.dpkg-old.


Either way, you only want it running the job once..... so run-parts ignores files with an '.' in them.

Michael Johnson
2007-08-10 07:07:36
Also, it will prevent trying to run .bak files. I know those aren't common on Linux, with most editors using ~, but they still show up. IMHO it's safer that way. Who knows what program x uses for backup extensions or whatever. Hmmm... could also be useful for putting data in that directory for use by the cron script. Probably not a good idea, but a thought nonetheless.


I just wish Apache 1.3 was smarter when running the scripts in apache/conf.d (I know, I should probably be running Apache 2... and I will. When I get time :)

Juliet Kemp
2007-08-10 07:50:55
chromatic - I like ls as a quick visual ;)


Robert - I don't think it's a bug, because it is documented, & as others have said, there are reasonable reasons for it.


Robert L - the --lsbsysinit switch filters out the .dpkg-* files (& a bunch of other stuff), but not *all* .foo. I think I prefer that, although I do see your & Michael's point about it being safer the Debian default way.


If I wanted to put data in that dir, I'd just make it non-executable :-)

John
2007-08-10 14:56:31
> I like ls as a quick visual ;)


"file" is only 2 characters longer than "ls". Using extensions to indicate the interpreter type reminds me of DOS and Windows. Unix is much nicer than that. Just think: cat.exe, ls.exe, which.csh, groups.sh, ispell.sh, ldd.sh, nohup.sh, etc. (you get the idea). Yuck!