#586486 dpkg: status database area is locked by another process. Is there a race condition?

Package:
aptitude
Source:
aptitude
Description:
terminal-based package manager
Submitter:
Regid Ichira
Date:
2021-09-22 03:21:04 UTC
Severity:
normal
#586486#5
Date:
2010-06-20 01:28:30 UTC
From:
To:
  When issuing the following commands:

    aptitude update; echo; aptitude -dyq --purge-unused safe-upgrade

I get:

many Get lines
Fetched 302kB in 1min 25s (3532B/s)
Reading package lists...

Reading package lists...
Building dependency tree...
Reading state information...
Reading extended state information...
Initializing package states...
mount: /usr is busy
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0B of archives. After unpacking 0B will be used.
E: Problem executing scripts DPkg::Post-Invoke 'mount -o remount,ro /usr'
E: Sub-process returned an error code
A package failed to install.  Trying to recover:
dpkg: status database area is locked by another process
Reading package lists...
Building dependency tree...
Reading state information...
Reading extended state information...
Initializing package states...


  There is a problem to remount /usr ro that is not related to aptitude.
Still, the dpkg process that is running is probably a child process of aptitude.
Aren't they suppose to communicate better, and avoid trying to remove a lock
that was placed by the other process?  I am using these commands for years.
Only lately dpkg has started to warn about the lock that was placed by the other
process.

#586486#14
Date:
2016-05-04 15:08:39 UTC
From:
To:

#586486#19
Date:
2016-07-16 10:33:18 UTC
From:
To:

#586486#24
Date:
2016-07-16 10:33:18 UTC
From:
To:

#586486#29
Date:
2017-06-06 20:58:43 UTC
From:
To:
2017-05-16 09:39 Julian Andres Klode:

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.

#586486#34
Date:
2021-09-22 03:15:36 UTC
From:
To:
-- 

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