run-parts doesn't run script with sh extension

Bug #38022 reported by Tomáš Hála on 2006-04-04
94
This bug affects 17 people
Affects Status Importance Assigned to Milestone
anacron (Ubuntu)
Low
Unassigned
cron (Debian)
Fix Released
Unknown
cron (Ubuntu)
Low
Unassigned
debianutils (Debian)
Fix Released
Unknown
debianutils (Ubuntu)
Wishlist
Unassigned

Bug Description

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) wrote :

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

Petr Tomeš (ptomes) wrote :

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

Tomáš Hála (tomas-monty) wrote :

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) wrote :

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

jhansonxi (jhansonxi) wrote :

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

Andrew Hampe (andrew-hampe) wrote :

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

Changed in debianutils:
status: New → Confirmed
Jean-Baptiste Lallement (jibel) wrote :

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

Thanks again !

Changed in debianutils:
status: Confirmed → Fix Released
robert (bobce01) on 2010-01-05
Changed in debianutils (Ubuntu):
status: Fix Released → Confirmed
Jean-Baptiste Lallement (jibel) wrote :

@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) wrote :

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.

Changed in debianutils (Ubuntu):
status: Confirmed → Fix Released

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.

Changed in cron (Debian):
status: Unknown → New
graemev (graeme-launchpad) wrote :

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"

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."

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

Changed in anacron (Ubuntu):
status: New → Triaged
Changed in cron (Ubuntu):
status: New → Triaged
Changed in anacron (Ubuntu):
importance: Undecided → Low
Changed in cron (Ubuntu):
importance: Undecided → Low
summary: - cron (run-parts) doesn't run script with sh extension
+ run-parts doesn't run script with sh extension
Changed in cron (Debian):
status: New → Fix Released
Jamie Strandboge (jdstrand) wrote :

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.

Changed in cron (Ubuntu):
status: Triaged → Won't Fix
Changed in debianutils (Debian):
status: Unknown → Fix Released
dregad (dregad) wrote :

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.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.