On Tue, Nov 10, 2009 at 12:10:26PM +1100, Jason White <ja...@jasonjgw.net> was heard to say: > 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.
/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. (replace <pid> with the PID that fuser gave you) Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
