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

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

Thanks,
Guillem