#include <hallo.h> * Ross Boylan [Sun, Feb 26 2006, 03:39:11PM]: > > > My efforts to trigger an update via aptitude update appear partly > > > successful; the timestamps on the file in apt-cacher's cache change. > > > But the file remains broken. > > After I sent the message, I tried again, and this time the timestamps > (of the files packages files under packages/) didn't update. I don't > understand what all the different files and directories, or nor > the conditions under which they should update. I had the impression > that apt-cacher wouldn't update from the net more than once in 24 > hours, though it's a fuzzy memory.
Check the config... timer based expiration was unreliable therefore it does quick online checks now. The expire_hours value needs to be set to 0 to get this behaviour, see comments in (current) apt-cacher.conf. > > > Possibly this is related to running out of disk space, though it looks > > > as if there should be enough. /var did fill up a few days ago, maybe > > > around when this started. > > I checked further and the problems began the day before the disk > (specifically /var; both apt and apt-cacher have dedicated partitions > for their big caches) filled. However, apt-cacher gets hit by an Oh, wait. You mean there was an out-of-space condition in the filesystem? That would explain it, one of the storage success checks in old versions (including 1.5.1) was broken and therefore in rare conditions (out-of-space, IO errors) incomplete files may have been stored. However, there is a workaround that should remove broken files from the cache (if it works as expected and headers files are still okay) - could you try the latest version from Sid please? When hiting broken files you will need to re-run apt-get but then it should work. > > > [EMAIL PROTECTED]:/usr/local/var/mirrors/apt-cacher/packages$ ls -l > > > linux.csua.berkeley.edu_debian_dists_testing_main_binary-i386_Packages.bz2 > > > -rw-r--r-- 1 www-data www-data 2435536 2006-02-25 21:35 > > > linux.csua.berkeley.edu_debian_dists_testing_main_binary-i386_Packages.bz2 > > > > > > The file at Berkeley, is > > > lftp linux.csua.berkeley.edu:/debian/dists/testing/main/binary-i386> ls > > > -rw-r--r-- 1 103 65534 2850393 Feb 25 20:17 Packages.bz2 > > > > Could you check the error.log file please? > /var/log/apt-cacher/error.log is empty; last time stamp Dec 29. Hm, okay, can be caused by the problem described above. > > I saw in your second message that you removed the broken file, that is > > just too bad since locating the problem is a bit complicated now. > > > > Eduard. > > I could try manually truncating the file. If you'd like me to do > that, let me know. Please also let me know how I should test it > afterwords, e.g., if I need to wait 24 hours, wait til the relevant > file is updated in the archive .... You can try to do that. It the file is not removed after the breakage should have been detected, then there is a problem :-( > However, there seem to still be a bunch of problems. Let me first > mention one that isn't. After I deleted the file and updated, I also ... > bzcat: Compressed file ends unexpectedly; > perhaps it is corrupted? *Possible* reason follows. > bzcat: Success > Input file = > security.debian.org_dists_sarge_updates_non-free_binary-i386_Packages.bz2, > output file = (stdout) > > It is possible that the compressed file(s) have become corrupted. > You can use the -tvv option to test integrity of such files. > > You can use the `bzip2recover' program to attempt to recover > data from undamaged sections of corrupted files. > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > In all the preceding cases, there is no .bz2 file in packages/, though > a .bz2.notify is in private/. Here's the file list for box2: I just got another bug report saying the same, apt-cacher-cleanup reporting problems with non-existent files. I will look at the problem later. > I've just updated to 1.5.2 from unstable. Looking in error.log so > far, I notice one oddity, the timeout message below: > -------------------------------------------------------------- > Sun Feb 26 15:29:56 2006|127.0.0.1|debug [881]: fetcher: try to fetch > http://linux.csua.berkeley.edu/debian/pool/main/a/apt-cacher/apt-cacher_1.5.2_all.deb > Sun Feb 26 15:29:56 2006|127.0.0.1|debug [881]: download agent: getting > http://linux.csua.berkeley.edu/debian/pool/main/a/apt-cacher/apt-cacher_1.5.2_all.deb > Sun Feb 26 15:29:57 2006|127.0.0.1|debug [880]: abort (timeout) > Sun Feb 26 15:29:58 2006|127.0.0.1|debug [881]: Entering critical section : > Callback, storing the header > Sun Feb 26 15:29:58 2006|127.0.0.1|debug [881]: Exiting critical section > Sun Feb 26 15:29:58 2006|127.0.0.1|debug [881]: Get is back > Sun Feb 26 15:29:58 2006|127.0.0.1|debug [881]: stored > http://linux.csua.berkeley.edu/debian/pool/main/a/apt-cacher/apt-cacher_1.5.2_all.deb > as /usr/local/var/mirrors/apt-cacher/packages/apt-cacher_1.5.2_all.deb > Sun Feb 26 15:29:58 2006|127.0.0.1|debug [881]: setting complete flag for > apt-cacher_1.5.2_all.deb > Sun Feb 26 15:29:58 2006|127.0.0.1|debug [881]: fetcher exiting > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Since the file was retrieved, I don't know if it's significant (e.g., > of timeouts that could be truncating the packages files on download). That "abort" line looks slightly missplaced, indeed. I will need to investigate later, no time right now. Eduard. -- Captain John Sheridan: No surrender, no retreat. -- Quotes from Babylon 5 -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
