Package: cron
Version: 3.0pl1-106
Severity: minor
Tags: patch
As has been mentioned in other bugreports (#485452, #535227), the
use of lockfile-progs by /etc/cron.daily/standard introduces an
unnecessary dependency on a low-Priority package, pulling it in by
default on every Debian install, even though you could get the same
functionality more easily via coreutils these days.
I attach three different sh scripts:
* flockdemo - which just shows how it works;
* standard.daily - a minimal modification of the cronjob;
* rewrite - a thoroughgoing reimplementation.
That third one is just there because I couldn't help myself - it has
extra features such as recognising ext4, but it deliberately changes
more or less every line and probably isn't suitable for use.
I also attach a patch that covers the minimal-change version plus
corresponding edits to the control file, removing the unnecessary
Recommends: lockfile-progs and the corresponding paragraph of the
package description. It should also fix bugs #179629 and #478967,
though not bug #333837.
Further comments on the standard cronjobs:
--
First, /etc/cron.monthly/standard has been empty for most of a
decade. Now would be a good time to get rid of it.
Second, the names of these cronjobs contravene a should in Debian
Policy 9.5, where it defines the namespace for these files:
# If a package wants to install a job that has to be executed via
# cron, it should place a file with the name of the package in one
# or more of the following directories:
Even anacron, which can't use plain anacron, gets as close as it
can with 0anacron. So the one remaining standard cronjob should
be named /etc/cron.daily/cron, leaving the namespace clear in case
a package ever turns up named standard.
Third, I agree with bug #473711: it's pointless to have every single
Debian machine spinning up every single hard disk to check the
status of lost+found directories every single day. Corrupted file
systems don't surreptitiously fsck themselves - doing the check more
often than once per boot is only going to be useful if the sysadmin
performs crucial system rescue procedures without paying attention,
and if you're going to assume that, you need to do a lot more kinds
of check! IMHO this task should belong to initscripts; if that's
too much trouble it could at least be factored out into a script
(something like /sbin/chklost+found) so that it can be called both
@reboot and @daily.
--
JBR
Ankh kak! (Ancient Egyptian blessing)
#!/bin/sh
FLOCK=~/lock# or whatever; not somewhere world-writable
umask 066 # don't let anyone else get a read-lock
: $FLOCK # always recreate it in case it's on a tmpfs
exec $FLOCK # use STDIN, don't interfere with output
if ! flock -n 0; then
echo 'Failed to acquire lock'
exit 1
fi
echo 'Running - now launch another to demonstrate collisions'
sleep 5
echo 'Finished' # $FLOCK automatically released
#!/bin/sh
# /etc/cron.daily/standard: standard daily maintenance script
# Written by Ian A. Murdock imurd...@gnu.ai.mit.edu
# Modified by Ian Jackson ijack...@nyx.cs.du.edu
# Modified by Steve Greenland stev...@debian.org
# Start in the root filesystem, make SElinux happy
cd /
bak=/var/backups
LOCKFILE=/var/lock/cron.daily
#
# Avoid running more than one at a time
#
umask 066
: $LOCKFILE
exec $LOCKFILE
if ! flock -n 0; then
cat EOF
Unable to run /etc/cron.daily/standard because lockfile $LOCKFILE
acquisition failed. This probably means that the previous day's
instance is still running. Please check and correct if necessary.
EOF
exit 1
fi
umask 022
#
# Backup key system files
#
if cd $bak ; then
cmp -s passwd.bak /etc/passwd || (cp -p /etc/passwd passwd.bak
chmod 600 passwd.bak)
cmp -s group.bak /etc/group || (cp -p /etc/group group.bak
chmod 600 group.bak)
if [ -f /etc/shadow ] ; then
cmp -s shadow.bak /etc/shadow || (cp -p /etc/shadow shadow.bak
chmod 600 shadow.bak)
fi
if [ -f /etc/gshadow ] ; then
cmp -s gshadow.bak /etc/gshadow || (cp -p /etc/gshadow gshadow.bak
chmod 600 gshadow.bak)
fi
fi
if cd $bak ; then
if ! cmp -s dpkg.status.0 /var/lib/dpkg/status ; then
cp -p /var/lib/dpkg/status dpkg.status
savelog -c 7 dpkg.status /dev/null
fi
fi
#
# Check to see if any files are in lost+found directories and warn admin
#
# Get a list of the (potential) ext2, ext3 and xfs l+f directories
# Discard errors, for systems not using any of these.
df -P --type=ext2 --type=ext3 --type=xfs 2/dev/null |
awk '/\/dev\// { print }' | sed -e 's/ [[:space:]]*/ /g' |
while read mount block used avail perc mp; do
[ $mp = / ] mp=
echo $mp/lost+found
done |
while read lfdir; do
# In each directory, look
