Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Bug#1019554: anacron: Anacron no longer seems to execute jobs

569 views
Skip to first unread message

Helge Kreutzmann

unread,
Sep 11, 2022, 4:50:05 PM9/11/22
to
Package: anacron
Version: 2.3-34
Severity: important

Since the upgrade to 2.3-34 anacron no longer seems to execute jobs. I
just expected my weekly cron jobs, but nothing happened. Since most
(ana)cronjobs are silent, it's hard to notice, but the (most
important) weekly jobs are not run.

Looking at my logs I noticed that the anacron log messages changed a
lot after the last update:
Sep 4 06:07:24 twentytwo anacron[818]: Job `cron.daily' started
Sep 4 06:07:24 twentytwo anacron[6013]: Updated timestamp for job `cron.daily' to 2022-09-04
Sep 4 06:07:25 twentytwo anacron[818]: Job `cron.daily' terminated
Sep 4 06:07:25 twentytwo anacron[818]: Normal exit (1 job run)
Sep 4 06:07:25 twentytwo systemd[1]: anacron.service: Deactivated successfully.
Sep 4 06:25:01 twentytwo CRON[10382]: (root) CMD (test -x /usr/sbin/anacron || { cd / && run-parts --report /etc/cron.daily; })
Sep 4 06:47:01 twentytwo CRON[17122]: (root) CMD (test -x /usr/sbin/anacron || { cd / && run-parts --report /etc/cron.weekly; })
Sep 4 07:30:01 twentytwo CRON[32520]: (root) CMD ([ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi)
Sep 4 07:32:43 twentytwo systemd[1]: Started Run anacron jobs.
Sep 4 07:32:43 twentytwo anacron[32625]: Anacron 2.3 started on 2022-09-04
Sep 4 07:32:43 twentytwo anacron[32625]: Normal exit (0 jobs run)
Sep 4 07:32:43 twentytwo systemd[1]: anacron.service: Deactivated successfully.
Sep 4 08:30:01 twentytwo CRON[35144]: (root) CMD ([ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi)
Sep 4 08:34:48 twentytwo systemd[1]: Started Run anacron jobs.
Sep 4 08:34:48 twentytwo anacron[35196]: Anacron 2.3 started on 2022-09-04
Sep 4 08:34:48 twentytwo anacron[35196]: Normal exit (0 jobs run)
Sep 4 08:34:48 twentytwo systemd[1]: anacron.service: Deactivated successfully.
Sep 4 09:30:01 twentytwo CRON[39613]: (root) CMD ([ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi)
Sep 4 09:32:24 twentytwo systemd[1]: Started Run anacron jobs.
Sep 4 09:32:24 twentytwo anacron[39634]: Anacron 2.3 started on 2022-09-04
Sep 4 09:32:24 twentytwo anacron[39634]: Normal exit (0 jobs run)
Sep 4 09:32:24 twentytwo systemd[1]: anacron.service: Deactivated successfully.
Sep 4 10:30:01 twentytwo CRON[42128]: (root) CMD ([ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi)
Sep 4 10:31:25 twentytwo systemd[1]: Started Run anacron jobs.
Sep 4 10:31:25 twentytwo systemd[1]: anacron.service: Deactivated successfully.
Sep 4 10:31:25 twentytwo anacron[42208]: Anacron 2.3 started on 2022-09-04
Sep 4 10:31:25 twentytwo anacron[42208]: Normal exit (0 jobs run)
Sep 4 11:30:01 twentytwo CRON[374183]: (root) CMD ([ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi)
Sep 4 11:30:33 twentytwo systemd[1]: Started Run anacron jobs.
Sep 4 11:30:33 twentytwo systemd[1]: anacron.service: Deactivated successfully.
Sep 4 11:30:33 twentytwo anacron[374192]: Anacron 2.3 started on 2022-09-04
Sep 4 11:30:33 twentytwo anacron[374192]: Normal exit (0 jobs run)
Sep 4 12:30:01 twentytwo CRON[382867]: (root) CMD ([ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi)
Sep 4 12:34:03 twentytwo systemd[1]: Started Run anacron jobs.
Sep 4 12:34:03 twentytwo anacron[382910]: Anacron 2.3 started on 2022-09-04
Sep 4 12:34:03 twentytwo anacron[382910]: Normal exit (0 jobs run)
Sep 4 12:34:03 twentytwo systemd[1]: anacron.service: Deactivated successfully.
Sep 4 13:30:01 twentytwo CRON[386353]: (root) CMD ([ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi)
Sep 4 13:34:13 twentytwo systemd[1]: Started Run anacron jobs.
Sep 4 13:34:13 twentytwo anacron[386396]: Anacron 2.3 started on 2022-09-04
Sep 4 13:34:13 twentytwo anacron[386396]: Normal exit (0 jobs run)
Sep 4 13:34:13 twentytwo systemd[1]: anacron.service: Deactivated successfully.
Sep 4 14:30:01 twentytwo CRON[389318]: (root) CMD ([ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi)
Sep 4 14:31:43 twentytwo systemd[1]: Started Run anacron jobs.
Sep 4 14:31:43 twentytwo anacron[389380]: Anacron 2.3 started on 2022-09-04
Sep 4 14:31:43 twentytwo anacron[389380]: Normal exit (0 jobs run)
Sep 4 14:31:43 twentytwo systemd[1]: anacron.service: Deactivated successfully.
Sep 4 15:30:01 twentytwo CRON[392039]: (root) CMD ([ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi)
Sep 4 15:31:48 twentytwo systemd[1]: Started Run anacron jobs.
Sep 4 15:31:48 twentytwo anacron[392066]: Anacron 2.3 started on 2022-09-04
Sep 4 15:31:48 twentytwo anacron[392066]: Normal exit (0 jobs run)
Sep 4 15:31:48 twentytwo systemd[1]: anacron.service: Deactivated successfully.
Sep 4 16:30:01 twentytwo CRON[393951]: (root) CMD ([ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi)
Sep 4 16:34:03 twentytwo systemd[1]: Started Run anacron jobs.
Sep 4 16:34:03 twentytwo anacron[393992]: Anacron 2.3 started on 2022-09-04
Sep 4 16:34:03 twentytwo anacron[393992]: Normal exit (0 jobs run)
Sep 4 16:34:03 twentytwo systemd[1]: anacron.service: Deactivated successfully.
Sep 4 17:30:01 twentytwo CRON[395824]: (root) CMD ([ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi)
Sep 4 17:32:03 twentytwo systemd[1]: Started Run anacron jobs.
Sep 4 17:32:03 twentytwo anacron[395837]: Anacron 2.3 started on 2022-09-04
Sep 4 17:32:03 twentytwo anacron[395837]: Normal exit (0 jobs run)
Sep 4 17:32:03 twentytwo systemd[1]: anacron.service: Deactivated successfully.
Sep 4 18:30:01 twentytwo CRON[402559]: (root) CMD ([ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi)
Sep 4 18:31:53 twentytwo systemd[1]: Started Run anacron jobs.
Sep 4 18:31:53 twentytwo anacron[402581]: Anacron 2.3 started on 2022-09-04
Sep 4 18:31:53 twentytwo anacron[402581]: Normal exit (0 jobs run)
Sep 4 18:31:53 twentytwo systemd[1]: anacron.service: Deactivated successfully.
Sep 4 19:30:01 twentytwo CRON[405906]: (root) CMD ([ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi)
Sep 4 19:30:48 twentytwo systemd[1]: Started Run anacron jobs.
Sep 4 19:30:48 twentytwo anacron[405913]: Anacron 2.3 started on 2022-09-04
Sep 4 19:30:48 twentytwo anacron[405913]: Normal exit (0 jobs run)
Sep 4 19:30:48 twentytwo systemd[1]: anacron.service: Deactivated successfully.
Sep 4 20:30:01 twentytwo CRON[409592]: (root) CMD ([ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi)
Sep 4 20:33:48 twentytwo systemd[1]: Started Run anacron jobs.
Sep 4 21:33:48 twentytwo anacron[412685]: Normal exit (0 jobs run)
Sep 4 21:33:48 twentytwo systemd[1]: anacron.service: Deactivated successfully.
Sep 4 21:49:36 twentytwo systemd[1]: anacron.timer: Deactivated successfully.
Sep 4 21:49:36 twentytwo systemd[1]: Stopped Trigger anacron every hour.
Sep 5 12:57:52 twentytwo systemd[1]: Started Trigger anacron every hour.
Sep 5 12:57:52 twentytwo systemd[1]: Started Run anacron jobs.
Sep 5 12:57:52 twentytwo anacron[816]: Anacron 2.3 started on 2022-09-05
Sep 5 12:57:52 twentytwo anacron[816]: Will run job `cron.daily' in 5 min.
Sep 5 12:57:52 twentytwo anacron[816]: Jobs will be executed sequentially
Sep 5 13:02:53 twentytwo anacron[816]: Job `cron.daily' started
Sep 5 13:02:53 twentytwo anacron[6009]: Updated timestamp for job `cron.daily' to 2022-09-05
Sep 5 13:02:54 twentytwo anacron[816]: Job `cron.daily' terminated
Sep 5 13:02:54 twentytwo anacron[816]: Normal exit (1 job run)
Sep 5 13:02:54 twentytwo systemd[1]: anacron.service: Deactivated successfully.
Sep 5 13:30:01 twentytwo CRON[6828]: (root) CMD ([ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi)
Sep 5 13:33:37 twentytwo systemd[1]: Started Run anacron jobs.
Sep 5 13:33:37 twentytwo anacron[6851]: Anacron 2.3 started on 2022-09-05
Sep 5 13:33:37 twentytwo anacron[6851]: Normal exit (0 jobs run)
Sep 5 13:33:37 twentytwo systemd[1]: anacron.service: Deactivated successfully.
Sep 5 17:51:29 twentytwo systemd[1]: Started Trigger anacron every hour.
Sep 5 17:51:29 twentytwo systemd[1]: Started Run anacron jobs.
Sep 5 17:51:29 twentytwo anacron[817]: Anacron 2.3 started on 2022-09-05
Sep 5 17:51:29 twentytwo anacron[817]: Normal exit (0 jobs run)
Sep 5 17:51:29 twentytwo systemd[1]: anacron.service: Deactivated successfully.
Sep 5 17:56:15 twentytwo systemd[1]: Started Run anacron jobs.
Sep 5 17:56:15 twentytwo anacron[3518]: Anacron 2.3 started on 2022-09-05
Sep 5 17:56:15 twentytwo anacron[3518]: Normal exit (0 jobs run)
Sep 5 17:56:15 twentytwo systemd[1]: anacron.service: Deactivated successfully.
Sep 5 18:08:32 twentytwo systemd[1]: anacron.timer: Deactivated successfully.
Sep 5 18:08:32 twentytwo systemd[1]: Stopped Trigger anacron every hour.
Sep 5 18:08:32 twentytwo systemd[1]: Stopping Trigger anacron every hour...
Sep 5 18:08:32 twentytwo systemd[1]: Started Trigger anacron every hour.
Sep 5 18:30:01 twentytwo CRON[86578]: (root) CMD ([ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi)
Sep 5 18:31:15 twentytwo systemd[1]: Started Run anacron jobs.
Sep 5 18:31:15 twentytwo anacron[91241]: Anacron 2.3 started on 2022-09-05
Sep 5 18:31:15 twentytwo anacron[91241]: Normal exit (0 jobs run)
Sep 5 18:31:15 twentytwo systemd[1]: anacron.service: Deactivated successfully.
Sep 5 19:30:01 twentytwo CRON[94520]: (root) CMD ([ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi)
Sep 5 19:33:38 twentytwo systemd[1]: Started Run anacron jobs.
Sep 5 19:33:38 twentytwo anacron[94565]: Anacron 2.3 started on 2022-09-05
Sep 5 19:33:38 twentytwo anacron[94565]: Normal exit (0 jobs run)
Sep 5 19:33:38 twentytwo systemd[1]: anacron.service: Deactivated successfully.
Sep 5 20:30:01 twentytwo CRON[101891]: (root) CMD ([ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi)
Sep 5 20:34:15 twentytwo systemd[1]: Started Run anacron jobs.
Sep 5 20:34:15 twentytwo anacron[101997]: Anacron 2.3 started on 2022-09-05
Sep 5 20:34:15 twentytwo anacron[101997]: Normal exit (0 jobs run)
Sep 5 20:34:15 twentytwo systemd[1]: anacron.service: Deactivated successfully.
Sep 5 21:04:01 twentytwo systemd[1]: anacron.timer: Deactivated successfully.
Sep 5 21:04:01 twentytwo systemd[1]: Stopped Trigger anacron every hour.
Sep 5 21:30:01 twentytwo CRON[4399]: (root) CMD ([ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi)
Sep 5 22:30:01 twentytwo CRON[7460]: (root) CMD ([ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi)
Sep 5 23:30:01 twentytwo CRON[10604]: (root) CMD ([ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi)
Sep 6 23:30:01 twentytwo CRON[4401]: (root) CMD ([ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi)
Sep 7 10:30:01 twentytwo CRON[7232]: (root) CMD ([ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi)
Sep 7 11:30:01 twentytwo CRON[14366]: (root) CMD ([ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi)
Sep 7 12:30:02 twentytwo CRON[18715]: (root) CMD ([ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi)
Sep 7 13:30:01 twentytwo CRON[22861]: (root) CMD ([ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi)
Sep 7 22:30:01 twentytwo CRON[8635]: (root) CMD ([ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi)
Sep 9 07:30:01 twentytwo CRON[4075]: (root) CMD ([ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi)
Sep 9 08:30:01 twentytwo CRON[6667]: (root) CMD ([ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi)
Sep 9 09:30:01 twentytwo CRON[10879]: (root) CMD ([ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi)
Sep 9 10:30:01 twentytwo CRON[12904]: (root) CMD ([ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi)

The update happended on the 5th…

I can investigate this more in the next days, I just manually run the backup.


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

Kernel: Linux 5.19.6 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to de_DE.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages anacron depends on:
ii libc6 2.34-7
ii lsb-base 11.2

Versions of packages anacron recommends:
ii cron [cron-daemon] 3.0pl1-149

Versions of packages anacron suggests:
ii exim4-daemon-light [mail-transport-agent] 4.96-3
pn powermgmt-base <none>
ii rsyslog [system-log-daemon] 8.2208.0-1

-- no debconf information

--
Dr. Helge Kreutzmann deb...@helgefjell.de
Dipl.-Phys. http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
Help keep free software "libre": http://www.ffii.de/
signature.asc

richard newton

unread,
Sep 12, 2022, 6:40:03 AM9/12/22
to
I had the same experience. After the upgrade to anacron 2.3-34
the systemd anacron.service and anacron.timer were left in a disabled state and had to be manually enabled and started.

From systemctl list-unit-files -

UNIT FILE                              STATE    PRESET
anacron.service                      disabled enabled
anacron.timer                         disabled enabled

Helge Kreutzmann

unread,
Sep 12, 2022, 12:50:04 PM9/12/22
to
Hello,
$ ls -tlr /var/spool/anacron/
insgesamt 12
-rw------- 1 root root 9 16. Aug 17:03 cron.monthly
-rw------- 1 root root 9 3. Sep 09:31 cron.weekly
-rw------- 1 root root 9 5. Sep 13:02 cron.daily

So cron.weekly is now overdue and cron.daily did not get touched since
the 5th, consistent with the update of the package.

Cron itself works, cron.hourly (which is not managed by anacron)
works.

I'm continuing to investigate, but I'm inclined to raise the severity.

Greetings

Helge
signature.asc

Lance Lin

unread,
Sep 13, 2022, 8:30:04 AM9/13/22
to
Hello Helge,

Thank you for your report. I'm happy to work on this.

> So cron.weekly is now overdue and cron.daily did not get touched since
> the 5th, consistent with the update of the package.
>

> Cron itself works, cron.hourly (which is not managed by anacron)
> works.
>

> I'm continuing to investigate, but I'm inclined to raise the severity.

Can you check to see if the anacron service is running? Richard Newton replied
in the thread and said the service was not running after the upgrade and it worked
after manually starting it.

The change I made was very small, adding 'TimeoutStopSec=infinity' to the service
based on an improvement that a user provided. I don't think this caused the issue
you are seeing.

I was able to verify that if I manually start the service, the cron.weekly/cron.daily
are updated with the current time. The upgrade went fine on my end but I would like

to track this down.

Perhaps the issue is that the service was already running when the upgrade happens

that the "new" service doesn't start? If so, I could add a preinst script to stop
the anacron service if it is running.

Lance Lin <lqi...@protonmail.com>
GPG Fingerprint:  4A31 DB5A 1EE4 096C 8739 9880 9036 4929 4C33 F9B7
signature.asc

Helge Kreutzmann

unread,
Sep 14, 2022, 4:20:03 PM9/14/22
to
Hello Lance,
On Tue, Sep 13, 2022 at 12:22:07PM +0000, Lance Lin wrote:
> Thank you for your report. I'm happy to work on this.

Thank you very much, this is highly appreciated.

> > So cron.weekly is now overdue and cron.daily did not get touched since
> > the 5th, consistent with the update of the package.
> >
>
> > Cron itself works, cron.hourly (which is not managed by anacron)
> > works.
> >
>
> > I'm continuing to investigate, but I'm inclined to raise the severity.
>
> Can you check to see if the anacron service is running? Richard Newton replied
> in the thread and said the service was not running after the upgrade and it worked
> after manually starting it.

helge@twentytwo:~$ ps aux | grep ana
helge 6448 0.0 0.0 7036 2272 tty4 S+ 22:08 0:00 grep ana

root@twentytwo:~# systemctl status anacron.service
◈ anacron.service - Run anacron jobs
Loaded: loaded (/lib/systemd/system/anacron.service; disabled; preset: enabled)
Active: inactive (dead)
Docs: man:anacron
man:anacrontab

> The change I made was very small, adding 'TimeoutStopSec=infinity' to the service
> based on an improvement that a user provided. I don't think this caused the issue
> you are seeing.
>
> I was able to verify that if I manually start the service, the cron.weekly/cron.daily
> are updated with the current time. The upgrade went fine on my end but I would like
>
> to track this down.
>
> Perhaps the issue is that the service was already running when the upgrade happens
>
> that the "new" service doesn't start? If so, I could add a preinst script to stop
> the anacron service if it is running.

Do you want me to try out something else, or should I now try to start it?

Btw., this machine is rebooted daily (i.e. only runs a few hours a day), so I
would have expected that after the next reboot anacron would come up …

Greetings

Helge
signature.asc

Mike Gerow

unread,
Sep 15, 2022, 4:00:03 PM9/15/22
to
I'm seeing the same issue, and I believe I've tracked it down to these
lines in the debian/anacron.postrm:

# Close bug #993348, remove dangling symlinks if they exist
if [ -f /etc/systemd/system/multi-user.target.wants/anacron.service ]; then
rm /etc/systemd/system/multi-user.target.wants/anacron.service
fi

if [ -f /etc/systemd/system/timers.target.wants/anacron.timer ]; then
rm /etc/systemd/system/timers.target.wants/anacron.timer
fi

These unconditionally delete the symlinks under
/etc/systemd/system/... that init-system-helpers/deb-systemd-helper
uses to determine if the service was "previously enabled". If they are
gone, the tool doesn't enable the service after the install.

At first blush it would appear that postrm shouldn't matter here since
we're upgrading the package, but critically the old postrm script is
called during an upgrade[1], which means the bug was actually in
2.3-33 but doesn't get triggered until the *next* time the package
happens to be upgraded.

[1]: https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#details-of-unpack-phase-of-installation-or-upgrade

Helge Kreutzmann

unread,
Sep 16, 2022, 10:00:04 AM9/16/22
to
Hello Lance,
On Tue, Sep 13, 2022 at 12:22:07PM +0000, Lance Lin wrote:
> Thank you for your report. I'm happy to work on this.

I'll try to start anacron manually on Sunday. So if you want to
investigate anything before I do so, please let me know.

Greetings

Helge
signature.asc

Adrian Immanuel Kiess

unread,
Sep 17, 2022, 2:20:03 AM9/17/22
to
Package: anacron
Version: 2.3-34
Followup-For: Bug #1019554

Dear Maintainer,

I experience the same bug after the last upgrade.

Anacron does no longer execute jobs on both of my Debian/testing installations.

Reading the already happened conversation, I now started anacron manually with:

# service anacron start

The anacron service now runs again; checked with:

# ps auxwww
root 249421 0.0 0.0 14480 1060 ? Ss 08:03 0:00
/usr/sbin/anacron -d -q -s

I will now wait, if anacron executes jobs again and for an upgraded package
which will fix the bug.

Thank you very much.

Sincerely,

Adrian Kiess


-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (990, 'testing')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.19.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages anacron depends on:
ii libc6 2.34-7
ii lsb-base 11.2

Versions of packages anacron recommends:
ii cron [cron-daemon] 3.0pl1-149

Versions of packages anacron suggests:
ii exim4-daemon-heavy [mail-transport-agent] 4.96-3
ii powermgmt-base 1.37
ii rsyslog [system-log-daemon] 8.2208.0-1

-- Configuration Files:
/etc/cron.d/anacron changed:
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
30 21 * * * root [ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi


-- no debconf information

Eric Cooper

unread,
Sep 17, 2022, 2:40:03 PM9/17/22
to
Package: anacron
Version: 2.3-34
Followup-For: Bug #1019554

Anacron seems to be failing for me recently also.
But in my case, an additional factor has changed (besides the new
version of anacron): I recently changed my power management settings
to suspend my computer when idle.

I have a backup script in root's crontab (set using "crontab -e") that
is supposed to run every night at 2am. Now the computer is asleep at
that hour, and the script does not get run any time the next day
either when the computer is awake.

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

Kernel: Linux 5.19.0-1-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages anacron depends on:
ii libc6 2.34-7
ii lsb-base 11.2

Versions of packages anacron recommends:
ii cron [cron-daemon] 3.0pl1-149

Versions of packages anacron suggests:
ii dma [mail-transport-agent] 0.13-1+b1
ii powermgmt-base 1.37

Lance Lin

unread,
Sep 19, 2022, 9:10:04 AM9/19/22
to
Mike,

> I'm seeing the same issue, and I believe I've tracked it down to these
> lines in the debian/anacron.postrm:
>

> # Close bug #993348, remove dangling symlinks if they exist
> if [ -f /etc/systemd/system/multi-user.target.wants/anacron.service ]; then
> rm /etc/systemd/system/multi-user.target.wants/anacron.service
> fi
>

> if [ -f /etc/systemd/system/timers.target.wants/anacron.timer ]; then
> rm /etc/systemd/system/timers.target.wants/anacron.timer
> fi
>

> These unconditionally delete the symlinks under
> /etc/systemd/system/... that init-system-helpers/deb-systemd-helper
> uses to determine if the service was "previously enabled". If they are
> gone, the tool doesn't enable the service after the install.
>

> At first blush it would appear that postrm shouldn't matter here since
> we're upgrading the package, but critically the old postrm script is
> called during an upgrade[1], which means the bug was actually in
> 2.3-33 but doesn't get triggered until the next time the package
> happens to be upgraded.

Thank you for tracking this down. I did make the change in -33.

Yes, I made the change to remove dangling symlinks on uninstall. I

didn't realize this was called on upgrades, so I've moved the logic

inside the "purge" case.

I propose to make the following change to anacron.postrm:

#!/bin/sh

set -e

if [ "$1" = "purge" ]; then
# here for historical reasons
rm -f /var/log/anacron /var/log/anacron.[0-9]*
rm -rf /var/spool/anacron

# Close bug #993348
rm /etc/systemd/system/multi-user.target.wants/anacron.service
rm /etc/systemd/system/timers.target.wants/anacron.timer
fi

#DEBHELPER#

Do you agree with this change?
signature.asc

Mike Gerow

unread,
Sep 19, 2022, 5:30:03 PM9/19/22
to
On Mon, 19 Sep 2022 12:59:59 +0000 Lance Lin <LQi...@protonmail.com> wrote:
>
> Thank you for tracking this down. I did make the change in -33.
>
> Yes, I made the change to remove dangling symlinks on uninstall. I
>
> didn't realize this was called on upgrades, so I've moved the logic
>
> inside the "purge" case.
>
> I propose to make the following change to anacron.postrm:
>
> #!/bin/sh
>
> set -e
>
> if [ "$1" = "purge" ]; then
> # here for historical reasons
> rm -f /var/log/anacron /var/log/anacron.[0-9]*
> rm -rf /var/spool/anacron
>
> # Close bug #993348
> rm /etc/systemd/system/multi-user.target.wants/anacron.service
> rm /etc/systemd/system/timers.target.wants/anacron.timer
> fi
>
> #DEBHELPER#
>
> Do you agree with this change?

Yes, that seems like it should prevent future upgrades from disabling
the service and the timer. Users that upgraded from -33 or -34 will
still need to manually re-enable the service and the timer, of course.
I'm capable of doing that with my systems, but I'll leave whether
that's acceptable in general up to you.

Roy Clark (kralcyor)

unread,
Sep 20, 2022, 4:10:04 AM9/20/22
to
Package: anacron
Version: 2.3-34
Followup-For: Bug #1019554

Dear Maintainer,

It seems that those symlinks(/etc/systemd/system/multi-user.target.wants/anacron.service and /etc/systemd/system/timers.target.wants/anacron.timer) are not "dangling". My testing in a debootstrap sid shows that installing anacron=2.3-32 will create those symlinks and purging the anaron package will remove those symlinks. It seems that those symlinks are handled by deb-systemd-helper in anacron.post{inst,rm}:
segment in anacron.postinst:
# Automatically added by dh_installsystemd/13.9.1
if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" = "abort-decon
figure" ] || [ "$1" = "abort-remove" ] ; then
# This will only remove masks created by d-s-h on package removal.
deb-systemd-helper unmask 'anacron.service' >/dev/null || true

# was-enabled defaults to true, so new installations run enable.
if deb-systemd-helper --quiet was-enabled 'anacron.service'; then
# Enables the unit on first installation, creates new
# symlinks on upgrades if the unit file has changed.
deb-systemd-helper enable 'anacron.service' >/dev/null || true
else
# Update the statefile to add new symlinks (if any), which need
to be
# cleaned up on purge. Also remove old symlinks.
deb-systemd-helper update-state 'anacron.service' >/dev/null ||
true
fi
fi
# End automatically added section

segment in anacron.postrm:
# Automatically added by dh_installsystemd/13.9.1
if [ "$1" = "remove" ]; then
if [ -x "/usr/bin/deb-systemd-helper" ]; then
deb-systemd-helper mask 'anacron.service' 'anacron.timer' >/dev/null || true
fi
fi

if [ "$1" = "purge" ]; then
if [ -x "/usr/bin/deb-systemd-helper" ]; then
deb-systemd-helper purge 'anacron.service' 'anacron.timer' >/dev/null || true
deb-systemd-helper unmask 'anacron.service' 'anacron.timer' >/dev/null || true
fi
fi
# End automatically added section

deb-systemd-helper is included in the init-system-helpers package, which is a essential package meaning it will be installed in all Debian system. So those symlinks will be purged when the anacron package is purged.

On Mon, 19 Sep 2022 12:59:59 +0000 Lance Lin <LQi...@protonmail.com> wrote:
> # Close bug #993348
> rm /etc/systemd/system/multi-user.target.wants/anacron.service
> rm /etc/systemd/system/timers.target.wants/anacron.timer

And concerning your proposed changes, it seems to me that if anacron.service or anacron.timer were disabled, these rm will cause anacron.postrm exited with error.

So I think there is no need to manually handle those symlinks and anacron.postrm should be reverted to the 2.3-32 revision.

-- System Information:
Debian Release: bookworm/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.19.0-1-amd64 (SMP w/2 CPU threads; PREEMPT)
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:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages anacron depends on:
ii libc6 2.34-8
ii sysvinit-utils [lsb-base] 3.05-5

Versions of packages anacron recommends:
ii cron [cron-daemon] 3.0pl1-149

Versions of packages anacron suggests:
ii exim4-daemon-light [mail-transport-agent] 4.96-4
ii powermgmt-base 1.37

Helge Kreutzmann

unread,
Sep 20, 2022, 3:10:04 PM9/20/22
to
Hello Lance,
On Tue, Sep 13, 2022 at 12:22:07PM +0000, Lance Lin wrote:
I started it on Sonday and the monthly stamp file was updated (I had
manully run the weekly jobs including updating the stamp file).
However, after several reboots, anacron gets not restartet:
◈ anacron.service - Run anacron jobs
Loaded: loaded (/lib/systemd/system/anacron.service; disabled; preset: enabled)
Active: inactive (dead)
Docs: man:anacron
man:anacrontab

helge@twentytwo:~$ ls -tlr /var/spool/anacron/
insgesamt 12
-rw------- 1 root root 9 18. Sep 06:22 cron.daily
-rw------- 1 root root 9 18. Sep 06:32 cron.weekly
-rw------- 1 root root 9 18. Sep 08:11 cron.monthly

As you can see, cron.daily is still on Sunday.

So something prevents anacron from starting.

Please tell me what helps tracing this down.

Greetings

Helge
signature.asc

Lance Lin

unread,
Sep 21, 2022, 9:50:03 AM9/21/22
to
Hello Helge,

> As you can see, cron.daily is still on Sunday.
>

> So something prevents anacron from starting.
>

> Please tell me what helps tracing this down.

I think Roy Clark's email on this list found the problem.

Someone had reported that there were dangling symlinks for the timer and service. They
suggested I should revert the anacron.postrm to the -32 version. I've made this change and
it is currently pushed to Debian testing.

Perhaps you could wait a few days until it is in unstable, or try the testing version, to
see if this fixes your issue?

Sorry for the inconvenience. I appreciate the report and help and hope this addresses the issue.
signature.asc

Helge Kreutzmann

unread,
Sep 29, 2022, 3:20:04 PM9/29/22
to
reopen 1019554
found 1019554 2.3-35
thanks

Hello Lance,
On Wed, Sep 21, 2022 at 01:40:18PM +0000, Lance Lin wrote:
> > As you can see, cron.daily is still on Sunday.
> >
>
> > So something prevents anacron from starting.
> >
>
> > Please tell me what helps tracing this down.
>
> I think Roy Clark's email on this list found the problem.
>
> Someone had reported that there were dangling symlinks for the timer and service. They
> suggested I should revert the anacron.postrm to the -32 version. I've made this change and
> it is currently pushed to Debian testing.
>
> Perhaps you could wait a few days until it is in unstable, or try the testing version, to
> see if this fixes your issue?
>
> Sorry for the inconvenience. I appreciate the report and help and hope this addresses the issue.

I received the update on monday (in testing), however, stamp files are
not updated:

ls -ltr /var/spool/anacron/
insgesamt 12
-rw------- 1 root root 9 18. Sep 08:11 cron.monthly
-rw------- 1 root root 9 25. Sep 06:38 cron.daily
-rw------- 1 root root 9 25. Sep 06:39 cron.weekly

(I had updated daily/weekly manually on sunday).

Is there something I need to do additionally?

root@twentytwo:~# systemctl status anacron.service
◈ anacron.service - Run anacron jobs
Loaded: loaded (/lib/systemd/system/anacron.service; disabled; preset: enabled)
Active: inactive (dead)
Docs: man:anacron
man:anacrontab

In syslog I see

Sep 29 18:30:01 twentytwo CRON[5114]: (root) CMD ([ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi)
Sep 29 19:30:01 twentytwo CRON[8138]: (root) CMD ([ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi)
Sep 29 20:30:01 twentytwo CRON[11425]: (root) CMD ([ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi)

/etc/init.d/anacron exists, /run/systemd/system is a directory.

If I issue the command manually, namely:
I get no output, however:
• anacron.service - Run anacron jobs
Loaded: loaded (/lib/systemd/system/anacron.service; disabled; preset: enabled)
Active: active (running) since Thu 2022-09-29 21:03:33 CEST; 11s ago
Docs: man:anacron
man:anacrontab
Main PID: 15251 (anacron)
Tasks: 1 (limit: 37643)
Memory: 320.0K
CPU: 1ms
CGroup: /system.slice/anacron.service
└─15251 /usr/sbin/anacron -d -q -s

Sep 29 21:03:33 twentytwo systemd[1]: Started Run anacron jobs.
Sep 29 21:03:33 twentytwo anacron[15251]: Anacron 2.3 started on 2022-09-29
Sep 29 21:03:33 twentytwo anacron[15251]: Will run job `cron.daily' in 5 min.
Sep 29 21:03:33 twentytwo anacron[15251]: Jobs will be executed sequentially

and after five minutes:
root@twentytwo:/var/log# systemctl status anacron.service
◈ anacron.service - Run anacron jobs
Loaded: loaded (/lib/systemd/system/anacron.service; disabled; preset: enabled)
Active: inactive (dead)
Docs: man:anacron
man:anacrontab

Sep 29 21:03:33 twentytwo systemd[1]: Started Run anacron jobs.
Sep 29 21:03:33 twentytwo anacron[15251]: Anacron 2.3 started on 2022-09-29
Sep 29 21:03:33 twentytwo anacron[15251]: Will run job `cron.daily' in 5 min.
Sep 29 21:03:33 twentytwo anacron[15251]: Jobs will be executed sequentially
Sep 29 21:08:33 twentytwo anacron[15251]: Job `cron.daily' started
Sep 29 21:08:33 twentytwo anacron[15484]: Updated timestamp for job `cron.daily' to 2022-09-29
Sep 29 21:08:33 twentytwo anacron[15251]: Job `cron.daily' terminated
Sep 29 21:08:33 twentytwo anacron[15251]: Normal exit (1 job run)
Sep 29 21:08:33 twentytwo systemd[1]: anacron.service: Deactivated successfully.

And now the stamp file is updated:
helge@twentytwo:~$ ls -tlr /var/spool/anacron/
insgesamt 12
-rw------- 1 root root 9 18. Sep 08:11 cron.monthly
-rw------- 1 root root 9 25. Sep 06:39 cron.weekly
-rw------- 1 root root 9 29. Sep 21:08 cron.daily

I'll check tomorrow after the next reboot, if anacron starts and
updates the stamp files but itself.

If yes, I of course close this bug (again).

Greetings

Helge

Greetings

Helge
signature.asc

Helge Kreutzmann

unread,
Sep 29, 2022, 3:30:03 PM9/29/22
to
Hello Lance,
On Thu, Sep 29, 2022 at 09:15:13PM +0200, Helge Kreutzmann wrote:
> Sep 29 20:30:01 twentytwo CRON[11425]: (root) CMD ([ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi)
>
> /etc/init.d/anacron exists, /run/systemd/system is a directory.

I just realized I read it incorrectly:

root@twentytwo:~# if [ ! -d /run/systemd/system ]; then echo "condition true"; fi
root@twentytwo:~#

So the check in the cron file is wrong! It should be
if [ -d /run/systemd/system ]; then …

Is this the solution? Or is there a downside in changing this? And I
definitely did not configure this manually. And if I log at old log
entries (when anacron was still working fine), the call is the same:
Jul 16 20:30:01 twentytwo CRON[15482]: (root) CMD ([ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi)

I did not backup /run, so I cannot check if /run/systemd/system was a
directory back then.

Maybe this additional information helps you tracking it down?
signature.asc

Lance Lin

unread,
Sep 30, 2022, 9:00:04 AM9/30/22
to
Hello Helge,

Thank you for your help in tracking this down. I apologize that the -35 revision didn't fix it.

> So the check in the cron file is wrong! It should be
> if [ -d /run/systemd/system ]; then …
>

> Is this the solution? Or is there a downside in changing this? And I
> definitely did not configure this manually. And if I log at old log
> entries (when anacron was still working fine), the call is the same:
> Jul 16 20:30:01 twentytwo CRON[15482]: (root) CMD ([ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi)

It could be. I have not changed d/cron.d at all. The only changes I made were to the service file (d/anacron.service) and that

was after input from another user saying the timeout (TimeoutStopSec=infinity). Perhaps this caused the problem? Maybe this is something
we could both test (e.g. deleting this line)? The user said the change was just strictly better and suited their needs as well as the typical functionality.
See Bug#915379.


If anacron was working before, this is now the only change since -32. If this breaks anacron, I am happy to remove the TimeoutStopSec line.
signature.asc

Helge Kreutzmann

unread,
Sep 30, 2022, 11:20:04 AM9/30/22
to
Hello Lance,
thanks for your analysis.

On Fri, Sep 30, 2022 at 12:53:09PM +0000, Lance Lin wrote:
> Thank you for your help in tracking this down. I apologize that the -35 revision didn't fix it.
>
> > So the check in the cron file is wrong! It should be
> > if [ -d /run/systemd/system ]; then …
> >
>
> > Is this the solution? Or is there a downside in changing this? And I
> > definitely did not configure this manually. And if I log at old log
> > entries (when anacron was still working fine), the call is the same:
> > Jul 16 20:30:01 twentytwo CRON[15482]: (root) CMD ([ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi)
>
> It could be. I have not changed d/cron.d at all. The only changes I made were to the service file (d/anacron.service) and that
>
> was after input from another user saying the timeout (TimeoutStopSec=infinity). Perhaps this caused the problem? Maybe this is something
> we could both test (e.g. deleting this line)? The user said the change was just strictly better and suited their needs as well as the typical functionality.
> See Bug#915379.

I just deleted this line in /usr/lib/systemd/system/anacron.service
and then run
systemctl restart anacron
(Hope this is right)

> If anacron was working before, this is now the only change since -32. If this breaks anacron, I am happy to remove the TimeoutStopSec line.

I'll report the outcome.

Greetings

Helge

P.S. Is there some explanation about the check of
"! -d /run/systemd/system"
?
signature.asc

Helge Kreutzmann

unread,
Oct 1, 2022, 8:51:19 AM10/1/22
to
Hello Lance,
On Fri, Sep 30, 2022 at 05:10:01PM +0200, Helge Kreutzmann wrote:
> On Fri, Sep 30, 2022 at 12:53:09PM +0000, Lance Lin wrote:
> > Thank you for your help in tracking this down. I apologize that the -35 revision didn't fix it.
> >
> > > So the check in the cron file is wrong! It should be
> > > if [ -d /run/systemd/system ]; then …
> > >
> >
> > > Is this the solution? Or is there a downside in changing this? And I
> > > definitely did not configure this manually. And if I log at old log
> > > entries (when anacron was still working fine), the call is the same:
> > > Jul 16 20:30:01 twentytwo CRON[15482]: (root) CMD ([ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi)
> >
> > It could be. I have not changed d/cron.d at all. The only changes I made were to the service file (d/anacron.service) and that
> >
> > was after input from another user saying the timeout (TimeoutStopSec=infinity). Perhaps this caused the problem? Maybe this is something
> > we could both test (e.g. deleting this line)? The user said the change was just strictly better and suited their needs as well as the typical functionality.
> > See Bug#915379.
>
> I just deleted this line in /usr/lib/systemd/system/anacron.service
> and then run
> systemctl restart anacron
> (Hope this is right)
>
> > If anacron was working before, this is now the only change since -32. If this breaks anacron, I am happy to remove the TimeoutStopSec line.
>
> I'll report the outcome.

I made two reboots today, but the stamp file did not get updated. So
no need to revert the change from #915379.

So it might be some coincidental change, but where? Systemd?

> P.S. Is there some explanation about the check of
> "! -d /run/systemd/system"
> ?

This is obviously not working. So I checked on a stable system, which
has seen many upgrades over the years. There this directory also
exists, anacron runs, but:

In the logs, I see
… anacron.service: Suceeded
and
… Started Trigger anacron every hour

I now checked old logs, and there I also see the messages about the
triggers.

So somehow the trigger is no longer executed.

The anacron config files are the same as on my stable system (after
the above change).

# systemctl status timers.target
• timers.target - Timer Units
Loaded: loaded (/lib/systemd/system/timers.target; static)
Active: active since Sat 2022-10-01 09:14:51 CEST; 4h 57min ago
Until: Sat 2022-10-01 09:14:51 CEST; 4h 57min ago
Docs: man:systemd.special(7)

Okt 01 09:14:51 twentytwo systemd[1]: Reached target Timer Units.

So timers should be there.

I see this in the logs until 2022-09-05.

According to /var/log/apt/history.log, the following packages were updated then:
Upgrade: josm-l10n:amd64 (0.0.svn18531+dfsg-1, 0.0.svn18543+dfsg-1), josm:amd64 (0.0.svn18531+dfsg-1, 0.0.svn18543+dfsg-1), node-write-file-atomic:amd64 (4.0.1+~4.0.0-2, 4.0.2+~4.0.0-1), libsoup-3.0-0:amd64 (3.1.3-2, 3.1.4-1), bash:amd64 (5.1-6.1+b1, 5.2~rc2-2), anacron:amd64 (2.3-33, 2.3-34), libsoup-3.0-common:amd64 (3.1.3-2, 3.1.4-1)

All the other packages look unrelated.

So I now remove anacron, and install 2.3-33.

dpkg -i anacron_2.3-33_amd64.deb
Vormals nicht ausgewähltes Paket anacron wird gewählt.
(Lese Datenbank ... 775863 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von anacron_2.3-33_amd64.deb ...
Entpacken von anacron (2.3-33) ...
anacron (2.3-33) wird eingerichtet ...
anacron.service is a disabled or a static unit not running, not starting it.
anacron.timer is a disabled or a static unit not running, not starting it.
Trigger für man-db (2.10.2-3) werden verarbeitet ...

And indeed:
root@twentytwo:/var/log# systemctl status anacron.service
◈ anacron.service - Run anacron jobs
Loaded: loaded (/lib/systemd/system/anacron.service; disabled; preset: enabled)
Active: inactive (dead)
Docs: man:anacron
man:anacrontab
root@twentytwo:/var/log# systemctl status anacron.timer
◈ anacron.timer - Trigger anacron every hour
Loaded: loaded (/lib/systemd/system/anacron.timer; disabled; preset: enabled)
Active: inactive (dead)
Trigger: n/a
Triggers: • anacron.service


Do you have any idea what both anacron.service and anacron.timer are
disabled?

So somehow anacron -34 disabled both the service and the timer.

Anything you want me to look at?

Next step would be how to properly enable them again…

Thanks!

Greetings

Helge
signature.asc

Lance Lin

unread,
Oct 7, 2022, 8:40:03 AM10/7/22
to
Hello Helge,

> Do you have any idea what both anacron.service and anacron.timer are
> disabled?
>
> So somehow anacron -34 disabled both the service and the timer.
>
> Anything you want me to look at?
>
> Next step would be how to properly enable them again…
>
> Thanks!
>
> Greetings
>
> Helge

I believe I've found the issue! Sorry it has taken so long to get back to you but I believe I have an answer.

It seems to be related to an inadequate cleanup. I don't have a great explanation but I found something that works.

The -33 version that removed the symlinks *somehow* (I am not sure) corrupted the whole install. I've found that
uninstalling anacron, removing the files associated with anacron and then re-installing the package (-35) will

yield a service that works.

Specifically, I removed:
/var/lib/systemd/deb-systemd-helper-*/ ... anacron files [might not be needed?]
/var/lib/dpkg/info/anacron.* files [might not be needed?]
/var/spool/anacron
/etc/anacrontab [I think this file is the problem!!]

Since you already have cron files, perhaps you could back them up, uninstall anacron, remove the files, and then
re-install anacron (-35), and then overlay your existing cron files? Would you be so kind to test this out on

your machine and see if this fixes it?

If it does, I will need to ask mentors on the best solution for this problem as it seems to be introduced in -33

but will only impact users who upgraded to -33 at some point. Going from -32 to -35, for instance, should not cause

problems. I've even made a notional -36 version to verify that once the service is running, the upgrade works smoothly.

Thank you for your help in tracking this down!
signature.asc

Helge Kreutzmann

unread,
Oct 9, 2022, 2:42:14 PM10/9/22
to
Hello Lin,
thanks for your analysis and answer.

On Fri, Oct 07, 2022 at 12:34:33PM +0000, Lance Lin wrote:
> I believe I've found the issue! Sorry it has taken so long to get back to you but I believe I have an answer.

Great! Thanks for your research.

> It seems to be related to an inadequate cleanup. I don't have a great explanation but I found something that works.
>
> The -33 version that removed the symlinks *somehow* (I am not sure) corrupted the whole install. I've found that
> uninstalling anacron, removing the files associated with anacron and then re-installing the package (-35) will
>
> yield a service that works.
>
> Specifically, I removed:
> /var/lib/systemd/deb-systemd-helper-*/ ... anacron files [might not be needed?]
> /var/lib/dpkg/info/anacron.* files [might not be needed?]
> /var/spool/anacron

I don't have them in my backups.

> /etc/anacrontab [I think this file is the problem!!]

This one is unchanged compared to older versions before the problem.

> Since you already have cron files, perhaps you could back them up, uninstall anacron, remove the files, and then
> re-install anacron (-35), and then overlay your existing cron files? Would you be so kind to test this out on
>
> your machine and see if this fixes it?

I will do this; however, I'm currently travelling with very little
access to my testing machine thus I will do this next weekend, I hope
this is ok.


> Thank you for your help in tracking this down!

You are welcome, thanks for tracking this down!

Greetings

Helge
signature.asc

Helge Kreutzmann

unread,
Oct 16, 2022, 12:41:19 PM10/16/22
to
Hello Lance,
On Fri, Oct 07, 2022 at 12:34:33PM +0000, Lance Lin wrote:
> I believe I've found the issue! Sorry it has taken so long to get back to you but I believe I have an answer.
>
> It seems to be related to an inadequate cleanup. I don't have a great explanation but I found something that works.
>
> The -33 version that removed the symlinks *somehow* (I am not sure) corrupted the whole install. I've found that
> uninstalling anacron, removing the files associated with anacron and then re-installing the package (-35) will
>
> yield a service that works.
>
> Specifically, I removed:
> /var/lib/systemd/deb-systemd-helper-*/ ... anacron files [might not be needed?]
> /var/lib/dpkg/info/anacron.* files [might not be needed?]
> /var/spool/anacron
> /etc/anacrontab [I think this file is the problem!!]
>
> Since you already have cron files, perhaps you could back them up, uninstall anacron, remove the files, and then
> re-install anacron (-35), and then overlay your existing cron files? Would you be so kind to test this out on
> your machine and see if this fixes it?

I did the following:
apt-get remove --purge anacron

root@twentytwo:~# ls /var/lib/systemd/deb-systemd-helper-* | grep anacron
root@twentytwo:~#
root@twentytwo:~# LC_ALL=C ls /var/lib/dpkg/info/anacron*
ls: cannot access '/var/lib/dpkg/info/anacron*': No such file or directory
root@twentytwo:~# LC_ALL=C ls /var/spool/anacron
ls: cannot access '/var/spool/anacron': No such file or directory
root@twentytwo:~# LC_ALL=C ls /etc/anacrontab
ls: cannot access '/etc/anacrontab': No such file or directory

root@twentytwo:~# mkdir ~/crontmp
root@twentytwo:~# mv -iv /etc/cron* ~/crontmp/
Datei umbenannt '/etc/cron.d' -> '/root/crontmp/cron.d'
Datei umbenannt '/etc/cron.daily' -> '/root/crontmp/cron.daily'
Datei umbenannt '/etc/cron.hourly' -> '/root/crontmp/cron.hourly'
Datei umbenannt '/etc/cron.monthly' -> '/root/crontmp/cron.monthly'
Datei umbenannt '/etc/crontab' -> '/root/crontmp/crontab'
Datei umbenannt '/etc/cron.weekly' -> '/root/crontmp/cron.weekly'

# apt-get install anacron

and then moved the cron files back.

root@twentytwo:~# LC_ALL=C ls -l /var/spool/anacron
total 0
-rw------- 1 root root 0 Oct 16 18:31 cron.daily
-rw------- 1 root root 0 Oct 16 18:31 cron.monthly
-rw------- 1 root root 0 Oct 16 18:31 cron.weekly

I report to you tomorrow if cron.daily gets updated …

> Thank you for your help in tracking this down!

Thanks for fixing it so swiftly and promptly.

Greetings

Helge
signature.asc

Helge Kreutzmann

unread,
Oct 17, 2022, 11:50:04 AM10/17/22
to
Hello Lance,
On Sun, Oct 16, 2022 at 06:35:37PM +0200, Helge Kreutzmann wrote:
> On Fri, Oct 07, 2022 at 12:34:33PM +0000, Lance Lin wrote:
> > Since you already have cron files, perhaps you could back them up, uninstall anacron, remove the files, and then
> > re-install anacron (-35), and then overlay your existing cron files? Would you be so kind to test this out on
> > your machine and see if this fixes it?
>
> I did the following:



After performing this yesterday, my daily and weekly activities kicked
in (as expected) and today, after a reboot, the daily activities have
been performed and
root@twentytwo:~# ls -ltr /var/spool/anacron/
insgesamt 12
-rw------- 1 root root 9 16. Okt 19:44 cron.weekly
-rw------- 1 root root 9 16. Okt 19:44 cron.monthly
-rw------- 1 root root 9 17. Okt 17:18 cron.daily

So all looks fine again.

Thanks for taking care!

(And now the hard part for getting all unstable/testing users fixed).
signature.asc

Doug Larrick

unread,
Oct 19, 2022, 8:50:03 PM10/19/22
to
I am among those whose cron.daily (etc.) stopped working due to this
bug. I am now on 2.3-35 and all I had to do to get it working again was:

| systemctl enable anacron.service
| systemctl start anacron.service

YMMV of course.

-Doug

Lance Lin

unread,
Oct 29, 2022, 9:00:04 AM10/29/22
to
> Hello
> I dont think to request a user action is a fair way to solve the issue.
> Update of anacron package should leave the fonctionnality as it is before the > update , that is running
> Please consider to solve the upgrade of anacron really.
> Best Regards

It is running and fixed. This only impacted a small number of testing users who upgraded to -33 where symlinks were removed.

Anyone who did not update to this version (-33) would not have these issues. Trying to override dh functionality is what caused this problem.
I don't think there needs to be more work done.

GPG Fingerprint:  4A31 DB5A 1EE4 096C 8739 9880 9036 4929 4C33 F9B7
------- Original Message -------
On Saturday, October 29th, 2022 at 7:35 PM, Grand T <grand...@msn.com> wrote:

Hello
I dont think to request a user action is a fair way to solve the issue.
Update of anacron package should leave the fonctionnality as it is before the update , that is running
Please consider to solve the upgrade of anacron really.
Best Regards


signature.asc

Tim Sattarov

unread,
Nov 23, 2022, 7:10:03 PM11/23/22
to
Hello

> > Hello> I dont think to request a user action is a fair way to solve the issue.
> > Update of anacron package should leave the fonctionnality as it is before the > update , that is
> running
> > Please consider to solve the upgrade of anacron really.
> > Best Regards
>
> It is running and fixed. This only impacted a small number of testing users who upgraded to -33
> where symlinks were removed.
>
> Anyone who did not update to this version (-33) would not have these issues. Trying to override dh
> functionality is what caused this problem.
> I don't think there needs to be more work done.
>
> Lance Lin <lqi...@protonmail.com>

I do not think it is a good idea to leave the package as is for users who were affected without a
postinst script that makes sure the service is enabled, if upgraded from versions -33 to -35.
I had to specifically look for this bug reports for anacron to make sure the system behaviour is "by
design" and anacron service is disabled for some specific purpose.
I know where to look for these bug reports and how to fix it, but many people do not and leaving
them like that without working cron subsystem is not fair.

Thank you
Tim
0 new messages