Your message dated Wed, 12 Aug 2009 13:48:52 +0200
with message-id <20090812114852.ga3...@gaara.hadrons.org>
and subject line Re: Bug#541179: dpkg installs/removes packages although
database is locked
has caused the Debian Bug report #541179,
regarding dpkg installs/removes packages although database is locked
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
541179: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=541179
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: dpkg
Version: 1.15.3.1
Severity: serious
Hi,
today I noticed something that I consider really serious:
I've started an aptitude purge gimp, without noticing that I had
an aptitude dist-upgrade (waiting for input, because of apt-listchanges)
running in another terminal, which I forgot to finish the day before.
Now would I have expected would be to stop and warn me about
the locked dpkg database.
But in reality aptitude proceeded (with displaying an error!) and
dpkg also proceeded and removed the package.
While still having the dist-upgrade open I can reproduce this:
% sudo dpkg -P
python3.1
(Reading database ... 260455 files and directories currently installed.)
Removing python3.1 ...
Purging configuration files for python3.1 ...
Processing triggers for man-db ...
Processing triggers for menu ...
Processing triggers for desktop-file-utils ...
However I guess that the dpkg status database is locked and
if I remove packages it should therefore not update the
database. But it does:
% dpkg -l python3.1
Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err:
uppercase=bad)
||/ Name Version Description
+++-====================-====================-========================================================
pn python3.1 <none> (no description available)
Given that I have a dist-upgrade running I fear that my dpkg
database will be inconsistent when this is finished, so this
problem is quiet serious.
Best Regards,
Patrick
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.29-2-686 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages dpkg depends on:
ii coreutils 7.4-2 The GNU core utilities
ii libc6 2.9-21 GNU C Library: Shared libraries
ii lzma 4.43-14 Compression method of 7z format in
dpkg recommends no packages.
Versions of packages dpkg suggests:
ii apt 0.7.21 Advanced front-end for dpkg
-- no debconf information
--- End Message ---
--- Begin Message ---
Hi!
On Wed, 2009-08-12 at 13:11:22 +0200, Patrick Schoenfeld wrote:
> On Wed, Aug 12, 2009 at 11:04:55AM +0200, Sven Joachim wrote:
> > On 2009-08-12 10:35 +0200, Patrick Schoenfeld wrote:
> > > Package: dpkg
> > > Version: 1.15.3.1
> > > Severity: serious
> > > today I noticed something that I consider really serious:
> > > I've started an aptitude purge gimp, without noticing that I had
> > > an aptitude dist-upgrade (waiting for input, because of apt-listchanges)
> > > running in another terminal, which I forgot to finish the day before.
> > > Now would I have expected would be to stop and warn me about
> > > the locked dpkg database.
> >
> > If it did not do that, then the database was almost surely not locked in
> > the first place. Here is what I got after starting aptitude's TUI as
> > root:
>
> well, at least, this was the case:
>
> p...@lisa ~ % ls -l /var/lib/dpkg/lock
> -rw-r----- 1 root root 0 12. Aug 11:17 /var/lib/dpkg/lock
>
> (there was also an aptitude lock file, but this is of little
> relevance for this).
The files are always present, that does not imply the db is currently
locked.
> Notable is that dpkg was not doing much, except waiting for
> apt-parsechanges to finish. So probably the lock handling is somewhat
> borked with respect to Dpkg::Pre-Install-Pkgs commands.
> > | % LANG=C sudo dpkg -P ed
> > | dpkg: status database area is locked by another process
> > `----
>
> Yeah, but this is somewhat the wrong testcase.
dpkg should not have even run when the Dpkg::Pre-Install-Pkgs commands
are run (refer to man apt.conf). Thus closing this bug report.
regards,
guillem
--- End Message ---
