[Aptitude-devel] Bug#1070027: apt: daily systemd service handles dpkg frontend locking incorrectly?

[Julian Andres Klode]

On Wed, Aug 07, 2024 at 12:05:54PM GMT, Vincent Lefevre wrote:
> On 2024-08-07 11:56:56 +0200, Julian Andres Klode wrote:
> > Control: reassign -1 aptitude
> > Control: retitle -1 aptitude: frontend lock support
> > 
> > On Wed, Aug 07, 2024 at 11:38:35AM GMT, Vincent Lefevre wrote:
> > > 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.
> > 
> > No that's nonsense. The frontend lock is exactly supposed to be held
> > while running dpkg (which runs the lock). This is working as designed.
> 
> WRONG! You can see above an error *without* using aptitude.
> Even though there may be a bug in aptitude, there is also
> a bug related to apt.

If you believe there is another bug then you are free to open another
one with a summary, but I am not going to read a wild goose chase thread
in this bug about another bug you discover while trying to figure out
what's going on with your aptitude.

The behavior you show here in this final email with your log is entirely
correct: apt-daily.service fails to run because you are holding the lock
in an apt execution. This is a feature, not a bug.

On upgrades, we do not restart or reload or otherwise interact with
either apt-daily service, and the services are ordered so they do not
run at the same time either; so you won't see races between the services
or races from the service being restarted and lose to a parent apt
process.

But either way, the service is designed to fail this way. There's a
reason it runs twice a day despite only needing to run once a day,
precisely to give it a chance to catch up if it missed a run due
to a lock.

Now you could make it wait for the frontend lock, but whether this
is advisable is another story, it certainly will make your original
bug report worse: apt is guaranteed to steal aptitude's lock if it
starts while aptitude is running, so it seems worthwhile to fix this
bug.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer                              i speak de, en