[Aptitude-devel] Bug#862714: system upgrade stopped, chiken-egg problem?

[Manuel A. Fernandez Montecelo]

2017-05-16 09:39 Julian Andres Klode:
>Control: reassign -1 aptitude
>
>On Tue, May 16, 2017 at 09:03:55AM +0200, Arturo Borrero Gonzalez wrote:
>> Package: libapt-pkg5.0
>> Version: 1.4.1
>> Severity: normal
>>
>> Dear apt team,
>>
>> thanks for your work, it's really apreciated :-)
>>
>> Today, I was doing an 'aptitude upgrade' in a server running stretch testing,
>> which was a bit outdated.
>>
>[...]
>> Processing triggers for libc-bin (2.24-9) ...
>> dpkg: error: dpkg status database is locked by another process
>> E: Sub-process /usr/bin/dpkg returned an error code (2)
>> Failed to perform requested operation on package.  Trying to recover:
>> dpkg: error: dpkg status database is locked by another process
>> E: Could not get lock /var/lib/dpkg/lock - open (11: Resource temporarily unavailable)
>> E: Unable to lock the administration directory (/var/lib/dpkg/), is another process using it?
>> E: Could not regain the system lock!  (Perhaps another apt or dpkg is running?)
>> E: Could not get lock /var/lib/dpkg/lock - open (11: Resource temporarily unavailable)
>> E: Unable to lock the administration directory (/var/lib/dpkg/), is another process using it?
>
>Thanks for the bug report. There is a known race condition between
>dpkg and apt tools, but I think we mostly worked around that for
>now in apt.
>
>The real fix for this is:
>
> https://lists.debian.org/debian-dpkg/2017/01/msg00044.html
>
>But that requires changes basically everywhere. Once that is solved
>on the dpkg side, we can fix stuff elsewhere. That is tracked in
>Bug #850417.
>
>Reassigning to aptitude for now, as maybe aptitude does not do
>its best to reduce the race as much as possible (keep the lock
>until just before DoInstall(), and lock again once that is
>done).
>
>If it does, I guess we should probably reassign to dpkg and
>forcemerge with 850417.

aptitude doesn't do anything special for this, and there are previous
bugs about it (copying it for future triage).

Even if maybe in practice it's better to do what you propose, I always
thought that it was (theoretically) the wrong way to deal with locks,
because in the interim between unlock in dpkg and the lock-again in
apt*-like tools another competing process can eat the cake.

But yeah, maybe by avoiding to do the perfect solution the end result is
worse.

In any case, I didn't have to do much time to deal with this, but even
if I did, I think that it's a potentially problematic change that it's
not good to implement in the "deep freeze".

So now, any resolution it'll have to wait until after the release,
sorry.


Cheers.
-- 
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>