Bug#1070027: apt: daily systemd service handles dpkg frontend locking incorrectly?
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 <vincent@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)
Reply to: