Bug#431909: aptitude: Lock file not removed after completion
On 7/6/07, Daniel Burrows [EMAIL PROTECTED] wrote: This patch should fix your problem. If you can rebuild aptitude with it applied and check whether it helps, that would be great. Daniel The warning message goes away now but /var/lock/aptitude still exists after exit. -- Web: http://wand.net.nz/~iam4/ Blog: http://iansblog.jandi.co.nz WAND Network Research Group -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#431909: aptitude: Lock file not removed after completion
On Tue, Jul 10, 2007 at 09:05:44PM +1200, Ian McDonald [EMAIL PROTECTED] was heard to say: On 7/6/07, Daniel Burrows [EMAIL PROTECTED] wrote: This patch should fix your problem. If you can rebuild aptitude with it applied and check whether it helps, that would be great. Daniel The warning message goes away now but /var/lock/aptitude still exists after exit. Yes, /var/lock/aptitude always exists. As I said before, it's not necessary to remove it and aptitude contains no code to do so (so if it was removed, it would be a bug!) Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#431909: aptitude: Lock file not removed after completion
On 7/11/07, Daniel Burrows [EMAIL PROTECTED] wrote: Yes, /var/lock/aptitude always exists. As I said before, it's not necessary to remove it and aptitude contains no code to do so (so if it was removed, it would be a bug!) OK, understand now. This bug is fixed then with the patch. -- Web: http://wand.net.nz/~iam4/ Blog: http://iansblog.jandi.co.nz WAND Network Research Group -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#431909: aptitude: Lock file not removed after completion
On 7/6/07, Daniel Burrows [EMAIL PROTECTED] wrote: This patch should fix your problem. If you can rebuild aptitude with it applied and check whether it helps, that would be great. Compiled and built. Waiting for problem to reoccur to see if fixed. The way to reproduce (for me) is to try and do aptitude upgrade very soon after they have come out - I think because one mirror is behind. I went to test this morning but was too slow and all the mirrors were updated... -- Web: http://wand.net.nz/~iam4/ Blog: http://iansblog.jandi.co.nz WAND Network Research Group -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#431909: aptitude: Lock file not removed after completion
Package: aptitude Version: 0.4.5.4-1 Severity: important When I do sudo aptitude -PV upgrade and it cannot get all the files I get this: W: Could not lock the cache file. Opening in read-only mode; any changes you make to the states of packages will NOT be preserved! immediately prior is this: Get:1 http://jandi3 unstable/main gedit-common 2.18.2-1 [3586kB] Err http://jandi3 unstable/main mozilla-plugin-vlc 0.8.6.c-3 404 Not Found Get:2 http://jandi3 unstable/main ssh 1:4.6p1-4 [1060B] Fetched 3587kB in 16s (220kB/s) (Reading database ... 183297 files and directories currently installed.) Preparing to replace gedit-common 2.18.1-1 (using .../gedit-common_2.18.2-1_all.deb) ... Unpacking replacement gedit-common ... Preparing to replace ssh 1:4.6p1-3 (using .../ssh_1%3a4.6p1-4_all.deb) ... Unpacking replacement ssh ... Setting up gedit-common (2.18.2-1) ... Setting up ssh (1:4.6p1-4) ... E: Failed to fetch http://jandi3:3142/ftp.us.debian.org/debian/pool/main/v/vlc/mozilla-plugin-vlc_0.8.6.c-3_i386.deb: 404 Not Found Reading package lists... Done Building dependency tree Reading state information... Done Reading extended state information Initializing package states... Done Reading task descriptions... Done Building tag database... Done I have checked and the lock file (/var/lock/aptitude) IS removed if aptitude is successful. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.20final_dccp (PREEMPT) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages aptitude depends on: ii apt [libapt-pkg-libc6.5 0.7.3Advanced front-end for dpkg ii libc6 2.5-11 GNU C Library: Shared libraries ii libgcc1 1:4.2-20070627-1 GCC support library ii libncursesw55.6-3Shared libraries for terminal hand ii libsigc++-2.0-0c2a 2.0.17-2 type-safe Signal Framework for C++ ii libstdc++6 4.2-20070627-1 The GNU Standard C++ Library v3 Versions of packages aptitude recommends: ii aptitude-doc-en [aptitude-doc 0.4.5.4-1 English manual for aptitude, a ter pn libparse-debianchangelog-perl none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#431909: aptitude: Lock file not removed after completion
On Fri, Jul 06, 2007 at 09:39:20AM +1200, Ian McDonald [EMAIL PROTECTED] was
heard to say:
When I do sudo aptitude -PV upgrade and it cannot get all the files I
get this:
W: Could not lock the cache file. Opening in read-only mode; any
changes you make to the states of packages will NOT be preserved!
immediately prior is this:
(...)
Reading task descriptions... Done
Building tag database... Done
You're saying the error appears here, right?
I have checked and the lock file (/var/lock/aptitude) IS removed if
aptitude is successful.
That would be surprising, since there is no code in aptitude to delete
it. aptitude uses fcntl locks, so once the program has exited the lock
will always be released by the kernel. However, there have been
multiple bugs that caused aptitude to claim it had failed to lock the
file when there was some other problem, and this looks like another one
to me.
The code in question first tries to open without a lock, then (if that
fails or produces an error) tries to open with a lock. If it succeeds
the second time, it assumes that it failed because of a lock the first
time (apt doesn't actually return this information, so I get to play a
game of reverse engineering what happened). Unfortunately, it doesn't
clear the global error state before doing this, so any errors that
happen before it tries to lock the cache will cause a spurious lock
failure.
This patch should fix your problem. If you can rebuild aptitude with
it applied and check whether it helps, that would be great.
Daniel
diff -r 84cd0521e303 src/generic/apt/apt.cc
--- a/src/generic/apt/apt.cc Tue Jul 03 07:06:43 2007 -0700
+++ b/src/generic/apt/apt.cc Thu Jul 05 20:54:36 2007 -0700
@@ -288,6 +288,9 @@ void apt_load_cache(OpProgress *progress
apt_source_list-ReadMainList();
bool simulate = aptcfg-FindB(PACKAGE ::Simulate, false);
+
+ // Clear the error stack so that we don't get confused by old errors.
+ consume_errors();
bool open_failed=!new_file-Open(*progress_bar, do_initselections,
(getuid() == 0) !simulate,
