On 2009-08-12 13:11 +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 >> > >> > 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. >> >> 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
The mere existence of this file does not tell whether it is locked, you need to run lsof as root to detect that. > (there was also an aptitude lock file, but this is of little > relevance for this). > > 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. This may be so, but that would not be dpkg's fault. >> | % LANG=C sudo dpkg -P ed >> | dpkg: status database area is locked by another process >> `---- > > Yeah, but this is somewhat the wrong testcase. Pardon me for not testing "aptitude dist-upgrade", that would have been somewhat inconvenient. But AFAICS in your example dpkg had not even a chance to run during the "aptitude dist-upgrade", so it cannot be blamed for not acquiring a lock. Sven -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
