Bug#924510: cron runs job at wrong time; ignores values in /etc/crontab; after upgrade to buster

[Tony Walker]

Package: cron
Version: 3.0pl1-132
Severity: normal

Dear Maintainer,

* What led up to the situation?

I upgraded to Buster from stretch and noticed that my cron jobs were running at ~7:38 AM
instead of the time in my /etc/crontab. After some troubleshooting, I did reinstall by
installing from 9.7 media followed immediately by apt full-upgrade. The problem persisted.
I then did the same on a different system and found that the problem exists on this
system as well (total of two out of two systems that exhibit the problem).

* What exactly did you do (or not do) that was effective (or
ineffective)?

I tried the default setting of 6:25 AM ["25 6 * * *"] and a few other times
(e.g., 1:00 AM ["0 1 * * *"]). cron seems to ignore all entries and the jobs always
run at ~7:38 AM. date and hwclock agree on current time. /etc/timezone is America/New_York
which is correct for me. TZ is not set anywhere that I can find. /var/spool/cron/crontabs
is empty, so there should be no other/duplicate jobs causing confusion. Also, the recent
shift to DST in the US did not change the behavior.

I googled, searched stackoverflow and bug reports, and posted in the forums. It appears
that I am the only person to observe this behavior, so I feel like a stupid user and have
been reluctant to send a report. However, I can reproduce the behavior on different
systems from a clean install using the default configuration.

* What was the outcome of this action?

Nothing seems to resolve the problem.

* What outcome did you expect instead?

I expected the jobs in the system crontab to run at the specified time.

-- Package-specific info:
--- EDITOR:


--- /usr/bin/editor:
/bin/nano

--- /usr/bin/crontab:
-rwxr-sr-x 1 root crontab 43600 Feb 24 15:56 /usr/bin/crontab

--- /var/spool/cron:
drwxr-xr-x 3 root root 4096 Mar 1 20:51 /var/spool/cron

--- /var/spool/cron/crontabs:
drwx-wx--T 2 root crontab 4096 Oct 7 2017 /var/spool/cron/crontabs

--- /etc/cron.d:
drwxr-xr-x 2 root root 4096 Mar 7 20:02 /etc/cron.d

--- /etc/cron.daily:
drwxr-xr-x 2 root root 4096 Mar 12 17:19 /etc/cron.daily

--- /etc/cron.hourly:
drwxr-xr-x 2 root root 4096 Mar 7 20:02 /etc/cron.hourly

--- /etc/cron.monthly:
drwxr-xr-x 2 root root 4096 Mar 7 20:02 /etc/cron.monthly

--- /etc/cron.weekly:
drwxr-xr-x 2 root root 4096 Mar 12 17:19 /etc/cron.weekly


-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cron depends on:
ii adduser 3.118
ii debianutils 4.8.6.1
ii init-system-helpers 1.56+nmu1
ii libc6 2.28-8
ii libpam-runtime 1.3.1-5
ii libpam0g 1.3.1-5
ii libselinux1 2.8-1+b1
ii lsb-base 10.2018112800
ii sensible-utils 0.0.12

Versions of packages cron recommends:
ii exim4-daemon-light [mail-transport-agent] 4.92-2

Versions of packages cron suggests:
ii anacron 2.3-27
pn checksecurity <none>
ii logrotate 3.14.0-4

Versions of packages cron is related to:
pn libnss-ldap <none>
pn libnss-ldapd <none>
pn libpam-ldap <none>
pn libpam-mount <none>
pn nis <none>
pn nscd <none>

-- no debconf information

Package: cron

Version: 3.0pl1-132

Severity: normal

Dear Maintainer,

   * What led up to the situation?

I upgraded to Buster from stretch and noticed that my cron jobs were running at ~7:38 AM 

instead of the time in my /etc/crontab. After some troubleshooting, I did reinstall by 

installing from 9.7 media followed immediately by apt full-upgrade. The problem persisted. 

I then did the same on a different system and found that the problem exists on this 

system as well (total of two out of two systems that exhibit the problem).

   * What exactly did you do (or not do) that was effective (or

     ineffective)?

I tried the default setting of 6:25 AM ["25 6 * * *"] and a few other times 

(e.g., 1:00 AM ["0 1 * * *"]). cron seems to ignore all entries and the jobs always 

run at ~7:38 AM. date and hwclock agree on current time. /etc/timezone is America/New_York 

which is correct for me. TZ is not set anywhere that I can find. /var/spool/cron/crontabs 

is empty, so there should be no other/duplicate jobs causing confusion. Also, the recent

shift to DST in the US did not change the behavior.

I googled, searched stackoverflow and bug reports, and posted in the forums. It appears

that I am the only person to observe this behavior, so I feel like a stupid user and have 

been reluctant to send a report. However, I can reproduce the behavior on different 

systems from a clean install using the default configuration.

   * What was the outcome of this action?

Nothing seems to resolve the problem.

   * What outcome did you expect instead?

I expected the jobs in the system crontab to run at the specified time.

-- Package-specific info:

--- EDITOR:

--- /usr/bin/editor:

/bin/nano

--- /usr/bin/crontab:

-rwxr-sr-x 1 root crontab 43600 Feb 24 15:56 /usr/bin/crontab

--- /var/spool/cron:

drwxr-xr-x 3 root root 4096 Mar  1 20:51 /var/spool/cron

--- /var/spool/cron/crontabs:

drwx-wx--T 2 root crontab 4096 Oct  7  2017 /var/spool/cron/crontabs

--- /etc/cron.d:

drwxr-xr-x 2 root root 4096 Mar  7 20:02 /etc/cron.d

--- /etc/cron.daily:

drwxr-xr-x 2 root root 4096 Mar 12 17:19 /etc/cron.daily

--- /etc/cron.hourly:

drwxr-xr-x 2 root root 4096 Mar  7 20:02 /etc/cron.hourly

--- /etc/cron.monthly:

drwxr-xr-x 2 root root 4096 Mar  7 20:02 /etc/cron.monthly

--- /etc/cron.weekly:

drwxr-xr-x 2 root root 4096 Mar 12 17:19 /etc/cron.weekly

-- System Information:

Debian Release: buster/sid

  APT prefers testing

  APT policy: (500, 'testing')

Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores)

Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE

Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash

Init: systemd (via /run/systemd/system)

LSM: AppArmor: enabled

Versions of packages cron depends on:

ii  adduser              3.118

ii  debianutils          4.8.6.1

ii  init-system-helpers  1.56+nmu1

ii  libc6                2.28-8

ii  libpam-runtime       1.3.1-5

ii  libpam0g             1.3.1-5

ii  libselinux1          2.8-1+b1

ii  lsb-base             10.2018112800

ii  sensible-utils       0.0.12

Versions of packages cron recommends:

ii  exim4-daemon-light [mail-transport-agent]  4.92-2

Versions of packages cron suggests:

ii  anacron        2.3-27

pn  checksecurity  <none>

ii  logrotate      3.14.0-4

Versions of packages cron is related to:

pn  libnss-ldap   <none>

pn  libnss-ldapd  <none>

pn  libpam-ldap   <none>

pn  libpam-mount  <none>

pn  nis           <none>

pn  nscd          <none>

-- no debconf information

[Tony Walker]

Thanks Christian,

My sys admin skills are fairly dated/rusty (I am an architect and programmer).
Either way, I am also an idiot.

I left out one detail that might have helped. The behavior I am describing is for
jobs that are in /etc/cron.daily, etc. What I missed is that the default system
crontab clearly puts anacron in control when it is installed. From the default system
crontab,“... test -x /usr/sbin/anacron || (cd / && run-parts --report /etc/cron.daily )"

Unfortunately, because I have rebuilt both of my Debian dev systems, I can’t say why
everything worked as I thought it should. However, it appears that I didn’t have
anacron installed and the upgrade pulled it in. That is what caused the change in
behavior for my cron jobs in /etc/cron.daily. “apt purge anacron” fixes my problem.

Having said that, I am sure it is documented somewhere and I missed it, but having
anacron “own” jobs in /etc/cron.* surprised me.

Sorry to waste your time and thanks for all of your (and the other maintainers)
hard work.

-- Tony Walker

> On Mar 14, 2019, at 2:24 AM, Christian Kastner <c...@debian.org> wrote:
>
> Hi,

>
> On 13.03.19 20:16, Tony Walker wrote:
>> I upgraded to Buster from stretch and noticed that my cron jobs were
>> running at ~7:38 AM
>> instead of the time in my /etc/crontab. After some troubleshooting, I
>> did reinstall by
>> installing from 9.7 media followed immediately by apt full-upgrade. The
>> problem persisted.
>> I then did the same on a different system and found that the problem
>> exists on this
>> system as well (total of two out of two systems that exhibit the problem).
>>
>> * What exactly did you do (or not do) that was effective (or
>> ineffective)?
>>
>> I tried the default setting of 6:25 AM ["25 6 * * *"] and a few other times
>> (e.g., 1:00 AM ["0 1 * * *"]). cron seems to ignore all entries and the
>> jobs always
>> run at ~7:38 AM. date and hwclock agree on current time. /etc/timezone
>> is America/New_York
>

> that sounds extremely odd. I don't even have a clue what could cause
> this in the code. I'm almost certain it's not the job database...
> perhaps parsing?
>
> What does `journalctl -t CRON` say? (If you don't use systemd, the
> default /etc/rsyslog.conf contains a line #cron ... that when you enable
> it, will log all cron messages to /var/log/cron.log).
>
> If those messages don't provide a clue, then the only thing I can think
> of is to rebuild in debug mode, and then to run cron in the foreground.
> It will then, quite verbosely, report about all the steps it takes. Let
> me know if you need such a build, I can provide you with one.
>
> Regards,
> Christian

[Georges Khaznadar]

Hi,

when cron jobs are under /etc/cron.daily, they are launched by anacron,
if this package is installed, because anacron takes control of the file
/etc/crontab

If you are eager to have some jobs done at a precise time everyday, you
should not put them in /etc/cron.daily, but rather edit root's own
crontab file. Anacron runs jobs in a pretty asynchronous mode ;)

I am closing this bugreport. PLease feel free to reopen it if you want.

Best regards, Georges.

--
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70