1. Forum
  2. Usenet
  3. LINUX.DEBIAN.MAINT.DPKG

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

    From Justin Servis@1:229/2 to All on Sun Mar 30 03:10:01 2025
    XPost: linux.debian.bugs.dist
    From: [email protected]

    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

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Guillem Jover@1:229/2 to Justin Servis on Tue May 6 04:10:01 2025
    XPost: linux.debian.bugs.dist
    From: [email protected]

    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

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)