Control: retitle -1 dpkg failure at "Setting up" due to dpkg frontend lock by
apt-get via apt-daily.service
On 2024-07-25 11:03:50 +0200, Vincent Lefevre wrote:
> According to the journalctl output:
>
> Jul 25 10:30:36 qaa systemd[1]: Reload requested from client PID 326242
> ('systemctl') (unit session-2.scope)...
> Jul 25 10:30:36 qaa systemd[1]: Reloading...
> Jul 25 10:30:37 qaa systemd[1]: Reloading finished in 153 ms.
> Jul 25 10:30:37 qaa systemd[1]: Starting apt-daily.service - Daily apt
> download activities...
> Jul 25 10:30:37 qaa systemd[1]: apt-daily.service: Deactivated successfully.
> Jul 25 10:30:37 qaa systemd[1]: Finished apt-daily.service - Daily apt
> download activities.
>
> but again, I did *not* do a systemctl. So either systemd is completely
> broken, or perhaps the systemctl was done by dpkg itself.
In /var/lib/dpkg/info/dpkg.postinst I can see
systemctl --system daemon-reload >/dev/null || true
I'm wondering whether this is the cause.
This line is there due to
# Due to #932360 in debhelper we need to explicitly tell systemd to reload.
> Note that in this latter case (I would not be surprised, because
> when this happens, this is *always* during an upgrade), even if
> aptitude had some fix of frontend locking, there would still be a
> conflict between aptitude and dpkg, both leading to a request a
> lock.
The reload is triggered with just
dpkg -i /var/cache/apt/archives/dpkg_1.22.9_amd64.deb
so aptitude and even apt aren't even involved in this bug:
Jul 25 11:47:56 qaa systemd[1]: Reload requested from client PID 333083
('systemctl') (unit session-2.scope)...
Jul 25 11:47:56 qaa systemd[1]: Reloading...
Jul 25 11:47:56 qaa systemd[1]: Reloading finished in 139 ms.
--
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
