cron forgets to run user jobs

[Brian J. Murrell]

Binary package hint: cron

On Lucid, users' cron jobs will just suddenly stop executing. A user can simply resubmit their crontab (i.e. crontab -e, make a trivial change, then save) and cron will start executing it again.

Witness:

# (grep CRON /var/log/syslog; zgrep CRON /var/log/syslog.*.gz) | grep " (brian) CMD"

/var/log/syslog.7.gz:Apr 3 07:03:01 linux CRON[13584]: (brian) CMD (fetchmail ...)
/var/log/syslog.7.gz:Apr 3 07:15:01 linux CRON[13709]: (brian) CMD (bin/...)
/var/log/syslog.7.gz:Apr 3 07:43:01 linux CRON[14068]: (brian) CMD (bin/...)
/var/log/syslog.7.gz:Apr 3 08:03:01 linux CRON[16662]: (brian) CMD (fetchmail ...)
/var/log/syslog.7.gz:Apr 3 08:15:01 linux CRON[17334]: (brian) CMD (bin/...)
/var/log/syslog.7.gz:Apr 3 09:03:02 linux CRON[19086]: (brian) CMD (fetchmail ...)
/var/log/syslog.7.gz:Apr 3 09:15:01 linux CRON[19442]: (brian) CMD (bin/...)
/var/log/syslog.7.gz:Apr 3 10:03:01 linux CRON[25487]: (brian) CMD (fetchmail ...)
/var/log/syslog.7.gz:Apr 3 10:15:01 linux CRON[25782]: (brian) CMD (bin/...)

As you can see, there are jobs which are supposed to run every hour but the last time they were run was a week ago.

And now have the user make a trivial change like just changing the time that fetchmail job runs from 3 minutes after every hour to 4 minutes and like magic, it starts executing again:

Apr 10 10:04:01 linux CRON[4814]: (brian) CMD (fetchmail ...)

Note that this only affects non-root user crontabs. root crontabs continue to run, or I would have noticed this more immediately. :-)

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: cron 3.0pl1-106ubuntu5
ProcVersionSignature: Ubuntu 2.6.32-22.36-generic 2.6.32.11+drm33.2
Uname: Linux 2.6.32-22-generic i686
Architecture: i386
Date: Sun Apr 10 09:54:47 2011
ProcEnviron:
 LANG=en_CA.UTF-8
 SHELL=/bin/bash
SourcePackage: cron

[Christian Kastner (ckk)]

With "root" crontabs (as opposed to "non-root"), do you mean the system crontabs /etc/crontab and /etc/cron.d, or root's actual crontab (via crontab -e as root)?

Is there any possibility of the crontabs temporarily disappearing (eg: remote filesystem)?

[Brian J. Murrell (brian-interlinx)]

On 11-04-18 12:26 PM, Christian Kastner wrote:
> With "root" crontabs (as opposed to "non-root"), do you mean the system
> crontabs /etc/crontab and /etc/cron.d, or root's actual crontab (via
> crontab -e as root)?

Both. All crontabs continue to run indefinitely except user crontabs.
that said, I have not seen this reproduce since filing this bug (which I
filed because at the time it had happened once again) so I don't have
any post-reproduction data to dig into yet.

> Is there any possibility of the crontabs temporarily disappearing (eg:
> remote filesystem)?

Nope, not at all.

[Christian Kastner (ckk)]

On 04/18/2011 07:09 PM, Brian J. Murrell wrote:
> On 11-04-18 12:26 PM, Christian Kastner wrote:
>> With "root" crontabs (as opposed to "non-root"), do you mean the system
>> crontabs /etc/crontab and /etc/cron.d, or root's actual crontab (via
>> crontab -e as root)?
>
> Both. All crontabs continue to run indefinitely except user crontabs.
> that said, I have not seen this reproduce since filing this bug (which I
> filed because at the time it had happened once again) so I don't have
> any post-reproduction data to dig into yet.

Well, the only thing I can think of that would match this scenario is if
you were using NIS+ or some other directory service and there was a
lookup problem (eg: connection down), but errors of that kind are logged
("ORPHAN")...

[Nathan Stratton Treadway (nathanst)]

Is it possible that these cron jobs worked correctly up until the system was rebooted, but then did not start up again after a reboot?

Are the user in question defined in /etc/passwd (as opposed to via LDAP or something like that)?

Do you see any "ORPHAN (no passwd entry)" messages in /var/log/syslog when cron is starting up?

(If your answers are "yes", "no", and "yes", respectively, then you may be hitting LP: #27520 ....)

[Matthias Andree (matthias-andree)]

Also note that ORPHAN may not show up until you edit /etc/init/cron.conf to start cron -L2... the Upstart conversion is incomplete and causes the cron service to ignore /etc/default/cron.

[Christian Kastner (ckk)]

No, -L<n> only affects logging of jobs. The ORPHAN messages come from the parsing part of the code, and always appear irregardless of any <n> value.

[dino99 (9d9)]

Closing that outdated report as EOL has been reached long time ago