On 2024-08-07 11:04:15 +0200, Guillem Jover wrote: > On Thu, 2024-07-25 at 11:03:50 +0200, Vincent Lefevre wrote: [...] > > With VERBOSE=2, I could get more details about this failure: > > > > Jul 25 13:22:16 qaa systemd[1]: Starting apt-daily.service - Daily apt > > download activities... > > Jul 25 13:22:16 qaa apt.systemd.daily[378644]: E: Could not get lock > > /var/lib/dpkg/lock-frontend. It is held by process 378454 (apt) > > Jul 25 13:22:16 qaa apt.systemd.daily[378644]: E: Unable to acquire the > > dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using > > it? > > Jul 25 13:22:16 qaa apt.systemd.daily[378637]: error encountered in cron > > job with "apt-get check". > > Jul 25 13:22:16 qaa systemd[1]: apt-daily.service: Deactivated successfully. > > Jul 25 13:22:16 qaa systemd[1]: Finished apt-daily.service - Daily apt > > download activities. > > > > Here, the failure occurs in the apt.systemd.daily, because the > > process used for the upgrade got the lock first. But it could > > be the other way round, as this could be seen with aptitude. > > So, as mentioned above, and as we saw earlier in the bug report, it looks > like the lock handling in the apt-daily.service is not working, and is > interfering with the current run. This needs to be fixed there > somehow. Reassigning.
OK. So, in short, apt keeps the lock for too long. The lock should be released by apt for triggers since a lock may be needed by some process run by a trigger. -- 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)
