Debian Bug report logs - #1101672
dpkg-db-backup.service causes high CPU usage from systemd due to restart loop

Reply or subscribe to this bug.

Display info messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Justin Servis <jservis82@gmail.com>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: dpkg-db-backup.service causes high CPU usage from systemd due to restart loop

Date: Sun, 30 Mar 2025 02:05:22 +0100

Package: dpkg
Version: 1.21.22
Severity: important
X-Debbugs-Cc: jservis82@gmail.com

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

Message #10 received at 1101672@bugs.debian.org (full text, mbox, reply):

From: Guillem Jover <guillem@debian.org>

To: Justin Servis <jservis82@gmail.com>, 1101672@bugs.debian.org

Subject: Re: Bug#1101672: dpkg-db-backup.service causes high CPU usage from systemd due to restart loop

Date: Tue, 6 May 2025 04:04:38 +0200

Control: tag -1 unreproducible moreinfo

Hi!

On Sun, 2025-03-30 at 02:05:22 +0100, Justin Servis wrote:
> Package: dpkg
> Version: 1.21.22
> Severity: important
> X-Debbugs-Cc: jservis82@gmail.com

> 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?

Thanks,
Guillem

Send a report that this bug log contains spam.