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. I have an APT::Update::Post-Invoke-Success hook that runs sync-available. This works well with apt but doesn't with aptitude: # apt-get update ... Merging available database in /tmp/apt-available.Z5Xd6H...done. Replacing available packages info, using /tmp/apt-available.Z5Xd6H. Information about 37373 packages was updated. ... # aptitude update ... 98% [Working]Merging available database in /tmp/apt-available.gUAoEz...done. dpkg: error: dpkg status database is locked by another process E: Problem executing scripts APT::Update::Post-Invoke-Success 'test x$SHELL = x/bin/sh -a x$USER = x && exec > /dev/null; test -x /usr/sbin/sync-available && /usr/sbin/sync-available' E: Sub-process returned an error code # Thanks for your work & regards Mario
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. '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
Hi, 2012-04-28 05:31 Daniel Hartwig: 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.
Dear Customer, We could not deliver your parcel. Shipment Label is attached to email. Regards, Shawn Burnett, Sr. Operation Manager.
-- Hello, How are you doing today? I sent you an email yesterday, did you receive it? It is a very important message, anyway reply back to confirm that you already got my message to enable me to give you more details.. Best Regards. Mrs. Ameena Essa