[Aptitude-devel] Bug#1069183: Bug#1069183: aptitude: already running package installs/upgrade get interrupted because of lost dpkg lock

[Christoph Anton Mitterer]

Hey David.

Thanks for your elaborate mail

On Wed, 2024-04-17 at 21:55 +0200, David Kalnischkies wrote:
> > Unpacking util-linux-extra (2.38.1-5+deb12u1) over (2.38.1-5+b1)
> > ...
> > Setting up util-linux-extra (2.38.1-5+deb12u1) ...
> > dpkg: error: dpkg frontend lock was locked by another process with
> > pid 1064194
> > Note: removing the lock file is always wrong, can damage the locked
> > area
> > and the entire system. See
> > <https://wiki.debian.org/Teams/Dpkg/FAQ#db-lock>.
> > E: Sub-process /usr/bin/dpkg returned an error code (2)
> 
> I am assuming here that unpacking and setting up of util-linux-extra
> worked fine and that dpkg run ended. The dpkg run after that, which
> would probably have installed other things failed due to a lock being
> held by something else…

I'd have expected the same, with perhaps the difference that my blind
assumption was that *everything* is done in one dpkg run, and thus it
would hold the lock over everything.


> 
> > Scanning processes...
> > Scanning processor microcode...
> > Scanning linux images...
> > Running kernel seems to be up-to-date.
> > The processor microcode seems to be up-to-date.
> > No services need to be restarted.
> > No containers need to be restarted.
> > No user sessions are running outdated binaries.
> > No VM guests are running outdated hypervisor (qemu) binaries on
> > this host.
> 
> This output (that I trimmed slightly) is from needrestart

Sure that output was all clear (also apt's retry),.. I merely included
it to show that when starting over, it simply moves one with the next
packages.
That is, I also don't think that this issue ever left a single package
back in half-configured state or so.
Actually I cannot even remember that I'd have ever seen broken packages
because of this (e.g. because other deps were no longer fulfilled).



> > Unfortunately it doesn't tell the name of pid 1064194 and the
> > offending process
> > is typically always already gone by then.
> 
> (Maybe report that as a feature request for dpkg to show some info
>  about the pid instead of just the number, but that might be hard to
>  implement.)
You think so? I'd have thought if it already knows the PID, it could
just print the `comm` line of that?



> 
> > But in any case, shouldn't apitude/apt/dpkg just permantenly hold
> > the lock
> > once the process has started until it finishes?
> 
> That is how it is supposed to be, but I think aptitude was never
> changed
> to make full use of the frontend lock. Probably unrelated to this
> issue,
> but a quick grep on aptitude shows me:
> > $ git grep -A 2 -- '->ReleaseLock' src/generic/apt/aptcache.cc
> > :1006:      apt_cache_file->ReleaseLock();
> > -1007-      bool dpkg_selections_saved =
> > dpkg_selections.save_selections();
> > -1008-      if (! apt_cache_file->GainLock())
> which is the old pattern of releasing the lock and calling dpkg in
> the
> hopes that nothing grabs it in the meantime, which was the practice
> before dpkg gained the frontend lock (these are aptitudes own methods
> that wrap _system->Lock() from libapt that does acquire the frontend
> and the dpkg lock – and also releases both if told so).
> 
> The solution here should be to hold onto the frontend lock for the
> entire run and do the lock&unlock dance for compatibility with the
> dpkg
> lock only. _system->LockInner() is part of that and grep has no hits
> for it in aptitude.
> 
> So, my suspicion is that aptitude doesn't use the frontend lock and
> is
> hence prune to other front ends grabbing the dpkg (and front end)
> lock
> the moment it releases the dpkg lock for dpkg. Hence the two fails
> and
> the run of needrestart takes long enough for the other front end to
> finish so that the last dpkg call aptitude makes succeeds again.

Well that sounds like a probably cause then. Though I still don't know
*what* then steals the lock. I can only think of the Icinga/Prometheus
probes.
There should be nothing else on my systems that doesn't come out-of-the
box (like apt systemd.timers or so).


Thanks,
Chris.