Control: reopen -1
Control: severity -1 important

On 2024-07-11 00:49:20 +0200, Guillem Jover wrote:
> libdpkg: Try to print the executable name of the lock contending process
> 
> Just printing the PID is not very useful to try to track down the
> contending process as its presence might be momentary and might no
> longer be present when the user tries to look for that specific PID.
> 
> Try to get the executable name to give a better hint to what might be
> going wrong.
> 
> Closes: #1070027

Since the problem occurred again, this time on the dpkg upgrade itself:

Unpacking dpkg (1.22.9) over (1.22.7) ...
Setting up dpkg (1.22.9) ...
dpkg: error: dpkg frontend lock was locked by /usr/bin/apt-get process with pid 
326336

But this is rather useless information. Perhaps it should also
write the full "ps -ef" output (something like that) to a file,
though this may be too late.

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. 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 PPID (with the process name) of 326242 would have been useful,
but systemd does not give it.

-- 
Vincent Lefèvre <[email protected]> - 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)

Reply via email to