[Aptitude-devel] Bug#666130: Bug#666130: aptitude: locks dpkg status while running APT::Update::Post-Invoke-Success

[Manuel A. Fernandez Montecelo]

Control: tags -1 + wontfix


Hi,

2012-04-28 05:31 Daniel Hartwig:
>On 29 March 2012 06:53, Mario 'BitKoenig' Holbe
><Mario.Holbe at tu-ilmenau.de> wrote:
>> Package: aptitude
>> Version: 0.6.6-1
>>
>> Hello,
>>
>> thanks for fixing #476399. Unfortunately there seems to be a semantic
>> difference between apt and aptitude: While apt releases all locks before
>> running APT::Update::Post-Invoke-Success, aptitude doesn't.
>>
>
>Hi
>
>To say "apt releases all locks before …" is inaccurate.  Both programs
>lock /var/lib/apt/lists for the full duration of the update, including
>when the Post-Invoke hooks are run.
>
>I could not find any documentation that mentions Post-Invoke is to be
>run without dpkg (or anything else) locked.  It is probably best to
>consider these hooks (and the equivalent dpkg hooks) as being for
>notification only, not to modify any  package databases directly.
>
>> I have an APT::Update::Post-Invoke-Success hook that runs sync-available.
>> This works well with apt but doesn't with aptitude:
>>
>
>> # aptitude update
>> ...
>> 98% [Working]Merging available database in /tmp/apt-available.gUAoEz...done.
>> dpkg: error: dpkg status database is locked by another process
>
>'apt-get update' has no need to lock /var/lib/dpkg.
>
>aptitude locks dpkg out of habit of being interactive;[1] it can not
>have another package manager change things from under it.  Even so, it
>would be possible to unlock dpkg for the time of the Post-Invoke hooks
>and try to reclaim it after (and before going interactive again), but
>this may lead to another process locking dpkg in the meantime.
>
>Another interactive manager, synaptic, also locks dpkg while it runs
>and during the Post-Invoke hooks.
>
>It should be possible to work-around the interactive programs by using
>Post-Invoke to notify another process (cron job or spawn a background
>task which waits for the unlock) that the update has happened.  This
>may not be satisfactory for you and I am open to suggestions and/or
>patches (we could wait for the lock to be released if there is
>contention[2]).
>
>There is an open request for apt/aptitude to perform this on
>update.[3] A general solution there would be ideal.
>
>[1] http://bugs.debian.org/564289
>[2] http://bugs.debian.org/498424
>[3] http://bugs.debian.org/478970


I agree with the above.  In the curses/interactive mode of aptitude for
example, the update can run multiple times, including while selections
are pending to install/remove/upgrade.

aptitute cannot have the state of the system being removed under its
feet and risk performing operations in an inconsistent state, so it can
run many scripts but not those which might modify the state.  The only
guarantee to do that is to have the locks on the database.

Unlocking before invoking these scripts can lead to problems if other
programs, e.g. unattended-upgrades, get the lock in between and change
the state of the system.

So I think that in principle this problem cannot be fix due to the
interactive nature of aptitude.


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