Your message dated Wed, 11 Nov 2009 03:20:26 -0800
with message-id <20091111112025.ga2...@hummingbird>
and subject line Re: Bug#555499: Residual lock file after running aptitude
has caused the Debian Bug report #555499,
regarding Residual lock file after running aptitude
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 [email protected]
immediately.)


-- 
555499: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=555499
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: aptitude
Version: 0.6.0.1-1
Severity: normal


ja...@jdc:~$ sudo aptitude update && sudo aptitude dist-upgrade
E: Could not get lock /var/lib/apt/lists/lock - open (11: Resource temporarily
u
navailable)
E: Couldn't lock list directory..are you root?
ja...@jdc:~$

but if I then run sudo rm /var/lib/apt/lists/lock
and re-run aptitude it works.

The problem is that this is happening frequently now - my guess is that lock
files are being left behind after aptitude terminates.

I'm running Debian Sid, XFS file system, kernel 2.6.31.5, x86_64 architecture,
and the problem only appeared recently (I can't be more specific other than
within the last week or so, and I'm tracking Sid with regular upgrades.)

-- Package-specific info:
aptitude 0.6.0.1 compiled at Oct 25 2009 23:00:16
Compiler: g++ 4.3.4
Compiled against:
  apt version 4.8.1
  NCurses version 5.7
  libsigc++ version: 2.0.18
  Ept support enabled.
  Gtk+ support disabled.

Current library versions:
  NCurses version: ncurses 5.7.20090803
  cwidget version: 0.5.13
  Apt version: 4.8.1
        linux-vdso.so.1 =>  (0x00007ffff5bfd000)
        libapt-pkg-libc6.9-6.so.4.8 => /usr/lib/libapt-pkg-libc6.9-6.so.4.8 
(0x00007f83b060c000)
        libncursesw.so.5 => /lib/libncursesw.so.5 (0x00007f83b03bb000)
        liblog4cxx.so.10 => /usr/lib/liblog4cxx.so.10 (0x00007f83affc8000)
        libsigc-2.0.so.0 => /usr/lib/libsigc-2.0.so.0 (0x00007f83afdc3000)
        libcwidget.so.3 => /usr/lib/libcwidget.so.3 (0x00007f83afaf2000)
        libept.so.0 => /usr/lib/libept.so.0 (0x00007f83af879000)
        libxapian.so.15 => /usr/lib/libxapian.so.15 (0x00007f83af523000)
        libz.so.1 => /usr/lib/libz.so.1 (0x00007f83af30c000)
        libsqlite3.so.0 => /usr/lib/libsqlite3.so.0 (0x00007f83af07f000)
        libboost_iostreams.so.1.40.0 => /usr/lib/libboost_iostreams.so.1.40.0 
(0x00007f83aee74000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x00007f83aec58000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f83ae948000)
        libm.so.6 => /lib/libm.so.6 (0x00007f83ae6c6000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f83ae4b0000)
        libc.so.6 => /lib/libc.so.6 (0x00007f83ae15d000)
        libutil.so.1 => /lib/libutil.so.1 (0x00007f83adf5a000)
        libdl.so.2 => /lib/libdl.so.2 (0x00007f83add56000)
        libaprutil-1.so.0 => /usr/lib/libaprutil-1.so.0 (0x00007f83adb33000)
        libapr-1.so.0 => /usr/lib/libapr-1.so.0 (0x00007f83ad8fe000)
        libuuid.so.1 => /lib/libuuid.so.1 (0x00007f83ad6fa000)
        librt.so.1 => /lib/librt.so.1 (0x00007f83ad4f2000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x00007f83ad2bb000)
        libbz2.so.1.0 => /lib/libbz2.so.1.0 (0x00007f83ad0ab000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f83b08d4000)
        libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007f83ace83000)
Terminal: linux
$DISPLAY not set.
`which aptitude`: /usr/bin/aptitude
aptitude version information:

aptitude linkage:

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.31.5 (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages aptitude depends on:
ii  apt [libapt-pkg-libc6. 0.7.24            Advanced front-end for dpkg
ii  libboost-iostreams1.40 1.40.0-2          Boost.Iostreams Library
ii  libc6                  2.10.1-5          GNU C Library: Shared libraries
ii  libcwidget3            0.5.13-1          high-level terminal interface libr
ii  libept0                0.5.29            High-level library for managing De
ii  libgcc1                1:4.4.2-2         GCC support library
ii  liblog4cxx10           0.10.0-1          A logging library for C++
ii  libncursesw5           5.7+20090803-2    shared libraries for terminal hand
ii  libsigc++-2.0-0c2a     2.0.18-2          type-safe Signal Framework for C++
ii  libsqlite3-0           3.6.19-3          SQLite 3 shared library
ii  libstdc++6             4.4.2-2           The GNU Standard C++ Library v3
ii  libxapian15            1.0.16-3          Search engine library
ii  zlib1g                 1:1.2.3.3.dfsg-15 compression library - runtime

Versions of packages aptitude recommends:
ii  apt-xapian-index              0.22       maintenance tools for a Xapian ind
ii  aptitude-doc-en [aptitude-doc 0.6.0.1-1  English manual for aptitude, a ter
ii  libparse-debianchangelog-perl 1.1.1-2    parse Debian changelogs and output
ii  sensible-utils                0.0.1      Utilities for sensible alternative

Versions of packages aptitude suggests:
pn  debtags                       <none>     (no description available)
pn  tasksel                       <none>     (no description available)

-- no debconf information



--- End Message ---
--- Begin Message ---
On Wed, Nov 11, 2009 at 07:42:53PM +1100, Jason White <[email protected]> was 
heard to say:
> Daniel Burrows <[email protected]> wrote:
>  
> >   /var/lib/apt/lists/lock is an fcntl lockfile, not a dotlock-style
> > lockfile.  i.e., its mere existence isn't enough for the lock to be
> > held; a currently running process has to be holding the lock.  Removing
> > the lockfile doesn't remove the lock; instead, it causes a second lock
> > to be created and locked separately (so whatever wanted exclusive
> > access no longer has it).
> > 
> >   You can track down who's holding the lock next time this happens.  The
> > program "fuser" from psmisc can tell you which PID has the file locked,
> > and "ps uax | grep <pid>" will usually produce the name of the culprit.
> 
> It's apt-get update as invoked by /etc/cron.daily/apt.

  OK, I'll close this then.  Feel free to file a new one against apt
or reopen this and reassign it.

  Daniel


--- End Message ---

Reply via email to