run-parts doesn't run script with sh extension

[Tomáš Hála]

With default cron configuration you can only place a shell script to /etc/cron.* directory and it is executed by run-parts via cron at the right time. But if the script has "sh" extension (e.g. script.sh) it is not executed without any warning even if it has correct execute rights (e.g. 755). The same will NOT happen if you place only symlink to the script in this directory with the same name.

[Tomáš Hála (tomas-monty)]

Correction:
The same WILL happen even if you place simlink with "sh" extension in the /etc/cron.* directory.

[Petr Tomeš (ptomes)]

This bug has been opened here: http://forum.ubuntu.cz/viewtopic.php?pid=6070

[Tomáš Hála (tomas-monty)]

Note: This behavior is documented in run-parts man page. But because it works differently in some other Linux distributions take this bugreport more likely as a discussion iniciation if it wouldn`t be better to run scripts with extension as well in behalf of portability.

[Ondřej Surý (ondrej)]

Since it's documented behaviour I am changing bug severity to Wishlist.

[jhansonxi (jhansonxi)]

I just rediscovered this restriction. I found a Debian bug for it already exists:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=472585

I updated the Cron HowTo to highlight this issue:
https://help.ubuntu.com/community/CronHowto

[Valerie Hampe (ashfire908)]

Switching status to Confirmed, since it's documented behavior.

[Jean-Baptiste Lallement (jibel)]

This has been solved in 2.19 with the addition of the --regex option.

Thanks again !

[Jean-Baptiste Lallement (jibel)]

@robert, why did you set the status to 'confirmed'. Do you know a way to reproduce this issue in the latest release ?

[Chris Vigelius (chris-vigelius)]

a quick look into /etc/crontab shows that this issue still exists at least in 9.10:

cat /etc/crontab
25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )

You can confirm this by executing run-parts --test /etc/cron.daily - this will show which programs would be executed without actually executing them.

To actually fix this problem, it would be necessary to add --regex='.*' to the respective run-parts calls in /etc/crontab. Simply having the --regex option is not sufficient when it is not actually used. See attached patch for details (which also fixes the same problem with /etc/anacrontab to avoid inconsistencies.

p.s. a similar problem exists with cron.d, which is *not* addressed by this patch. The solution is probably the same as given here, unfortunately I do not know where the cron.d entries are executed from.

[Jean-Baptiste Lallement (jibel)]

We can't do that by default because there might be some config files backups left around by dpkg (package.dpkg -old and -new) and users do not expect those files to be executed. So the regex has to ignore those files.

[graemev (graeme-launchpad)]

Just stumbled over this in karmic ... my backups weren't running: (the string to look for is tsm)

root@graeme-laptop:/etc/cron.daily# run-parts --test --report /etc/cron.daily
/etc/cron.daily/0anacron
/etc/cron.daily/apport
<..elided...>
/etc/cron.daily/standard
/etc/cron.daily/sysklogd

root@graeme-laptop:/etc/cron.daily# ls *.suffix
tsm-backup.suffix

root@graeme-laptop:/etc/cron.daily# mv tsm-backup.suffix tsm-backup
root@graeme-laptop:/etc/cron.daily# run-parts --test --report /etc/cron.daily
/etc/cron.daily/0anacron
/etc/cron.daily/apport
<..elided...>
/etc/cron.daily/standard
/etc/cron.daily/sysklogd
/etc/cron.daily/tsm-backup

root@graeme-laptop:/etc/cron.daily# cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=9.10
DISTRIB_CODENAME=karmic
DISTRIB_DESCRIPTION="Ubuntu 9.10"

[Jean-Baptiste Lallement (jibel)]

The behavior of run-parts is documented in its manual page:
"If neither the --lsbsysinit option nor the --regex option is given then the names must consist entirely of upper and lower case letters, digits, underscores, and hyphens."

[Scott James Remnant (Canonical) (canonical-scott)]

Simply using ".*" as the regex would introduce new bugs, as editor swap files, dpkg backup files, etc. would all be run

A better regex is required

[Jamie Strandboge (jdstrand)]

This is "Won't Fix" upstream, and not something that we want to diverge from Debian on. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=68561 for details. Essentially, we don't want to allow a '.' because of .dpkg-old and .dpkg-dist files. If you would still like this fixed in Ubuntu, I encourage you to work with upstream (Debian) on a fix.

[dregad (dregad)]

I can live with run-parts not executing files containing a '.', but it would certainly make things easier to troubleshoot if the system actually logged information about skipping a script, instead of silently doing so.

[rychu (rychu++)]

I completely agree with @dregad that it would help a lot if there is any information about skipping a script because of a dot. I lost plenty of time troubleshooting smartmontools exec command because of that.
IMO statement "If neither the --lsbsysinit option nor the --regex option is given then the names must consist entirely of upper and lower case letters, digits, underscores, and hyphens." isn't enough, on man page. I read it twice and it didn't bring my attention and help me understand where my issue is. It should be explicitly written that scripts with dots are skipped.