Hi, On 2024-06-03 00:38:01 +0200, Guillem Jover wrote: > Hi! > > On Mon, 2024-04-29 at 04:37:18 +0200, Vincent Lefevre wrote: > > On 2024-04-29 03:05:50 +0200, Guillem Jover wrote: > > > I don't think dpkg is at fault here, I assume something else is either > > > getting activated in the middle of the transaction while the package > > > manager frontend driving dpkg has released the lock (which it should > > > not), or the package manager frontend driving dpkg is performing the > > > locking dance incorrectly. > > > > Isn't dpkg able to install/uninstall a set of packages in an atomic > > way (where dpkg itself would set a lock at the beginning and release > > the lock once every install/uninstall has been done, so that a lock > > failure would not be possible in the middle of the installation)? > > Sure, but that's not how apt-based frontends do it, as they call > dpkg multiples times over an upgrade process.
Why do they do that while it is possible to give dpkg several packages to install (upgrade)? And why doesn't the frontend log the different calls in/var/log/apt/history.log? I'm talking specifically about https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070027#19 > Checking around I see that the systemd apt-daily.timer triggered at just > the same time, so that seems like the most likely culprit. So I guess it > makes sense for this report to be cloned and reassigned or so. Hmm... That was also the case for me. Let's recall: Start-Date: 2024-04-28 22:05:30 [...] Error: Sub-process /usr/bin/dpkg returned an error code (2) End-Date: 2024-04-28 22:05:34 and in the journalctl output at this time: Apr 28 22:05:33 disset systemd[1]: Reloading requested from client PID 58469 ('systemctl') (unit session-796.scope)... Apr 28 22:05:33 disset systemd[1]: Reloading... Apr 28 22:05:34 disset systemd[1]: Reloading finished in 102 ms. Apr 28 22:05:34 disset systemd[1]: Starting apt-daily.service - Daily apt download activities... Apr 28 22:05:34 disset systemd[1]: fstrim.timer: Deactivated successfully. Apr 28 22:05:34 disset systemd[1]: Stopped fstrim.timer - Discard unused filesystem blocks once a week. Apr 28 22:05:34 disset systemd[1]: Stopping fstrim.timer - Discard unused filesystem blocks once a week... Apr 28 22:05:34 disset systemd[1]: Started fstrim.timer - Discard unused filesystem blocks once a week. Apr 28 22:05:34 disset systemd[1]: Reloading requested from client PID 58516 ('systemctl') (unit session-796.scope)... Apr 28 22:05:34 disset systemd[1]: Reloading... Apr 28 22:05:34 disset systemd[1]: Reloading finished in 110 ms. Apr 28 22:05:34 disset systemd[1]: apt-daily.service: Deactivated successfully. Apr 28 22:05:34 disset systemd[1]: Finished apt-daily.service - Daily apt download activities. But I've never requested a reloading at this time! So there's something broken related to systemd. -- 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)
