Package: aptitude Version: 1.21.22 Severity: important
Hey. May very well be an issue in APT or rather dpkg, still, since I always see it from aptitude, I report it here. Please re-assign accordingly. I'm seeing this since quite some releases and also every now and then in unstable (though probably far less there, as I only run my workstation on unstable, but all servers on stable). When I concurrently upgrade my servers (~60) via aptitude, out of that number arround 10 see the already running install/upgrade process suddenly interrupted with message like: Unpacking util-linux-extra (2.38.1-5+deb12u1) over (2.38.1-5+b1) ... Setting up util-linux-extra (2.38.1-5+deb12u1) ... dpkg: error: dpkg frontend lock was locked by another process with pid 1064194 Note: removing the lock file is always wrong, can damage the locked area and the entire system. See <https://wiki.debian.org/Teams/Dpkg/FAQ#db-lock>. dpkg: error: dpkg frontend lock was locked by another process with pid 1064194 Note: removing the lock file is always wrong, can damage the locked area and the entire system. See <https://wiki.debian.org/Teams/Dpkg/FAQ#db-lock>. Scanning processes... Scanning processor microcode... Scanning linux images... Running kernel seems to be up-to-date. The processor microcode seems to be up-to-date. No services need to be restarted. No containers need to be restarted. No user sessions are running outdated binaries. No VM guests are running outdated hypervisor (qemu) binaries on this host. E: Sub-process /usr/bin/dpkg returned an error code (2) E: Sub-process dpkg --set-selections returned an error code (2) E: Couldn't revert dpkg selection for approved remove/purge after an error was encountered! Processing triggers for man-db (2.11.2-2) ... Processing triggers for libc-bin (2.36-9+deb12u4) ... Press Return to continue, 'q' followed by Return to quit. Performing actions... Retrieving bug reports... Done (and then I continue in a new run). Unfortunately it doesn't tell the name of pid 1064194 and the offending process is typically always already gone by then. Could be check_apt from Icinga or could be /usr/share/prometheus-node-exporter-collectors/apt_info.py from prometheus-node-exporter-collectors . But in any case, shouldn't apitude/apt/dpkg just permantenly hold the lock once the process has started until it finishes? Or could this be a case where something ignores and subsequently breaks the lock? Thanks, Chris.
