• Bug#1101672: dpkg-db-backup.service causes high CPU usage from systemd

    From Guillem Jover@21:1/5 to Justin Servis on Tue May 6 04:10:01 2025
    XPost: linux.debian.maint.dpkg

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)