Hi,
When cron finds a crontab file has the wrong permissions
(and perhaps the wrong owner, I didn't check) it refuses
to execute the cronjobs in that file until the file
is deleted and re-created. It is not enough to
correct the problem and touch the file.
This makes diagnosing and fixing the problem more difficult.
The following script demonstrates the problem:
-----------------<snip>---------------
# Tidy up before we start.
rm -f /etc/cron.d/foo /tmp/foo
sleep 60
# Establish crontab
cat - >/etc/cron.d/foo <<EOF
* * * * * root printf 'Running\n'
EOF
sleep 60
# Cron job runs (email delivered to root)
chmod g+w /etc/cron.d/foo
sleep 60
# Cron job runs
# No error in syslog
cat - >/etc/cron.d/foo <<EOF
#* * * * * root printf 'Running\n'
EOF
sleep 60
# Get error in syslog looking like
#/usr/sbin/cron[1764]: (*system*foo) WRONG INODE INFO (/etc/cron.d/foo)
cat - >/etc/cron.d/foo <<EOF
* * * * * root printf 'Running\n'
EOF
sleep 60
# Cron job does not run.
chmod g-w /etc/cron.d/foo
touch /etc/cron.d/foo
sleep 60
# Cron job still does not run.
-----------------<snip>---------------
-- Package-specific info:
--- EDITOR:
--- usr/bin/editor:
/bin/nano
--- /usr/bin/crontab:
-rwxr-sr-x 1 root crontab 30248 Dec 18 17:46 /usr/bin/crontab
--- /var/spool/cron
drwxr-xr-x 5 root root 4096 Mar 8 2005 /var/spool/cron
--- /var/spool/cron/crontabs
drwx-wx--T 2 root crontab 4096 Jan 27 16:10 /var/spool/cron/crontabs
-- System Information:
Debian Release: 6.0.1
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages cron depends on:
ii adduser 3.112+nmu2 add and remove users and groups
ii debianutils 3.4 Miscellaneous utilities specific t
ii dpkg 1.15.8.10 Debian package management system
ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib
ii libpam-runtime 1.1.1-6.1 Runtime support for the PAM librar
ii libpam0g 1.1.1-6.1 Pluggable Authentication Modules l
ii libselinux1 2.0.96-1 SELinux runtime shared libraries
ii lsb-base 3.2-23.2squeeze1 Linux Standard Base 3.2 init scrip
Versions of packages cron recommends:
ii lockfile-progs 0.1.15 Programs for locking and unlocking
ii postfix [mail-transport-agent 2.7.1-1 High-performance mail transport ag
Versions of packages cron suggests:
ii anacron 2.3-14 cron-like program that doesn't go
pn checksecurity <none> (no description available)
ii logrotate 3.7.8-6 Log rotation utility
Versions of packages cron is related to:
pn libnss-ldap <none> (no description available)
pn libnss-ldapd <none> (no description available)
pn libpam-ldap <none> (no description available)
pn libpam-mount <none> (no description available)
pn nis <none> (no description available)
pn nscd <none> (no description available)
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
On 05/03/2011 10:59 PM, Karl O. Pinc wrote:
> When cron finds a crontab file has the wrong permissions
> (and perhaps the wrong owner, I didn't check) it refuses
> to execute the cronjobs in that file until the file
> is deleted and re-created. It is not enough to
> correct the problem and touch the file.
The problem here is that once cron detects an error with that file, it
removes it from its internal database, after which it is no longer
monitored for updates. The only way a new name gets added to the
database is when the mtime of /etc/cron.d/ changes, which is why
touching a file therein is not sufficient.
We already added the abilitiy to force a rescan for dangling symlinks
(see #433609). I generalized this feature to cover the cases of broken
ownership/modes. cron will complain about it every minute instead of
once, however. This is slightly crude, but as this appears to be a
fringe case, I think it's an adequate solution.
Christian