Your message dated Sat, 9 Aug 2025 01:19:51 +0200
with message-id <[email protected]>
and subject line Re: Bug#1101672: dpkg-db-backup.service causes high CPU usage
from systemd due to restart loop
has caused the Debian Bug report #1101672,
regarding dpkg-db-backup.service causes high CPU usage from systemd due to
restart loop
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1101672: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1101672
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: dpkg
Version: 1.21.22
Severity: important
X-Debbugs-Cc: [email protected]
Dear Maintainer,
On multiple Debian 12 (Bookworm) systems, the dpkg-db-backup.service unit
begins running at midnight and enters a rapid restart loop. This causes systemd
(PID 1) to consume excessive CPU (often 100%) until systemd's start-limit-hit
is triggered.
The service logs show that it starts and deactivates "successfully", but
systemd appears to consider it a failure and restarts it repeatedly. This
creates rapid log entries, spawns processes, and can overwhelm lightweight
systems (e.g., virtual machines).
Steps to reproduce:
1. Let a Debian 12 system idle until midnight with the default timer enabled
2. Observe CPU usage via `top` or `htop` (systemd will be at or near 100%)
3. Check `journalctl -u dpkg-db-backup.service` for repeated start/fail cycles
Workaround:
Disabling the timer and masking the service resolves the issue:
'sudo systemctl disable --now dpkg-db-backup.timer sudo systemctl mask
dpkg-db-backup.service'
This behavior affects both virtual and physical Debian 12 machines that have
not been modified beyond using Docker and standard updates. Please investigate
whether the unit file needs an adjusted Restart= policy or if the script exits
too quickly to be considered successful.
Thank you!
-- Package-specific info:
This system uses merged-usr-via-aliased-dirs, going behind dpkg's
back, breaking its core assumptions. This can cause silent file
overwrites and disappearances, and its general tools misbehavior.
See <https://wiki.debian.org/Teams/Dpkg/FAQ#broken-usrmerge>.
-- System Information:
Debian Release: 12.10
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-32-cloud-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.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 dpkg depends on:
ii libbz2-1.0 1.0.8-5+b1
ii libc6 2.36-9+deb12u10
ii liblzma5 5.4.1-0.2
ii libmd0 1.0.4-2
ii libselinux1 3.4-1+b6
ii libzstd1 1.5.4+dfsg2-5
ii tar 1.34+dfsg-1.2+deb12u1
ii zlib1g 1:1.2.13.dfsg-1
dpkg recommends no packages.
Versions of packages dpkg suggests:
ii apt 2.6.1
pn debsig-verify <none>
-- no debconf information
--- End Message ---
--- Begin Message ---
Hi!
On Tue, 2025-05-06 at 04:04:38 +0200, Guillem Jover wrote:
> Control: tag -1 unreproducible moreinfo
> On Sun, 2025-03-30 at 02:05:22 +0100, Justin Servis wrote:
> > Package: dpkg
> > Version: 1.21.22
> > Severity: important
> > X-Debbugs-Cc: [email protected]
>
> > On multiple Debian 12 (Bookworm) systems, the dpkg-db-backup.service
> > unit begins running at midnight and enters a rapid restart loop. This
> > causes systemd (PID 1) to consume excessive CPU (often 100%) until
> > systemd's start-limit-hit is triggered.
>
> I have no readily available bookworm system running systemd. But I cannot
> see this behavior on one of my systems running sid with systemd.
>
> The only difference I can see in the systemd timer between bookworm
> and sid is the addition of Persistent=true. And for the dpkg-db-backup
> script only a couple of commits that do not seem relevant.
>
> > The service logs show that it starts and deactivates "successfully",
> > but systemd appears to consider it a failure and restarts it repeatedly.
> > This creates rapid log entries, spawns processes, and can overwhelm
> > lightweight systems (e.g., virtual machines).
>
> Could you parse those log entries?
>
> > Steps to reproduce:
> > 1. Let a Debian 12 system idle until midnight with the default timer
> > enabled
> > 2. Observe CPU usage via `top` or `htop` (systemd will be at or near 100%)
> > 3. Check `journalctl -u dpkg-db-backup.service` for repeated start/fail
> > cycles
>
> > Workaround:
> > Disabling the timer and masking the service resolves the issue:
> >
> > 'sudo systemctl disable --now dpkg-db-backup.timer sudo systemctl mask
> > dpkg-db-backup.service'
> >
> > This behavior affects both virtual and physical Debian 12 machines that
> > have not been modified beyond using Docker and standard updates. Please
> > investigate whether the unit file needs an adjusted Restart= policy or
> > if the script exits too quickly to be considered successful.
>
> The only thing I can think of is that the script itself is failing for
> some reason. Do you see any error output in some of the log files?
> Perhaps add «set -x» to the dpkg-db-backup script to see what's going
> on?
>
> Are backups created at all under /var/backups/? Do you have any
> package performing any automatic package management actions at the
> same time at midnight?
Given that there has been no other similar reports of this, and that
no further information has been provided, I'm going to be closing this
report. Feel free to reopen with further information, or if this
problem gets reproduced or reappears.
Thanks,
Guillem
--- End Message ---
