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.montez...@gmail.com>
_______________________________________________
Aptitude-devel mailing list
Aptitude-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/aptitude-devel
