On 01/09/15 17:47, Tony van der Hoff wrote: > On 01/09/15 16:43, Cindy-Sue Causey wrote: >> On 9/1/15, Elimar Riesebieter <riese...@lxtec.de> wrote: >>> * Tony van der Hoff <t...@vanderhoff.org> [2015-09-01 14:17 +0200]: >>> >>>> On this jessie box I have started to see /var/lib/apt/lists/partial >>>> gradually filling the entire 2.7 GiB /var partition with hundreds of >>>> smallish files. Google show some results for a similar, but not >>>> identical problem for Ubuntu but I can't find anything matching this. >>>> >>>> This problem has developed over the last few days. >>>> >>>> A partial directory listing is attached (to circumvent wrapping). >>>> >>>> Can anyone suggest a remedy to this problem, please? >>> >>> Try >>> >>> # apt-get clean >>> >>> From apt-get(8): >>> >>> clean clears out the local repository of retrieved package files. It >>> removes everything but the lock file from /var/cache/apt/archives/ and >>> /var/cache/apt/archives/partial/. >>> >>> So after an apt-get update /var/lib/apt/lists/partial should be >>> recharged at least to zero size. >> >> >> >> Let us know if it starts filling back up again. I'd already started an >> answer and had to run outside and... put the trash can on the curb. >> Part of that answer was to say that location is where at least apt >> (via apt-get update) temporarily stores "partial" files as its >> downloading updates from our *_CHOICE_* of repositories. If partial >> continues magically self-propagating and not emptying, obviously >> something needs dissected/triggered/toggled off if it's not you >> manually, consciously performing related [functions] that would result >> in that activity. >> >> If you use something other than apt (apt-get) to update your software, >> do they offer the option to update automatically? Maybe that's toggled >> on? >> >> I'm just... looking at your output there and comparing it to mine. >> Your partial for this one, e.g.: >> >> 4584913 Sep 1 13:58 >> ftp.uk.debian.org_debian_dists_jessie_main_i18n_Translation-en.bz2 >> >> You're talking about a zip file that got hung up there for some >> reason. Maybe it's not completely downloaded so then you have to track >> down why... >> >> Or maybe the system's not finishing the transaction after a successful >> download for some reason? >> >> In my case, I've actually sat here and watched it run live. Those >> partials *APPEAR* to become what's in the next step up, the parent >> directory, /var/lib/apt/lists. >> >> So the question is potentially two-fold. Why is there SO MUCH of that >> activity if user is NOT manually/knowingly generating it.... and/or >> why is the process not completing successfully if it's a legitimately >> approved auto-update? >> >> Speaking firsthand, one way it MIGHT happen is if someone is on >> something like dialup or alternately if they only access the Internet >> sporadically (i.e. disconnect unexpectedly throughout the day). Those >> update related downloads would get interrupted, and that MIGHT be one >> cause for what's showing in OP's partial directory. >> >> My take on this is coming from firsthand experience rather than >> knowing how Debian technically works. I've seen something like OP's >> directory happen on my system but can't remember the exact >> circumstances now. In my case of being on dialup, the appearance has >> occasionally been that a repository's server has cut updates off >> because the server's tired of struggling under the 967 BYTES download >> rate on my end...... >> >> Cindy :) >> >> PS Ok, I just checked my inbox one more time before sending this. >> Elimar and David replied with David's thought being similar to my own. >> Compression was a word I was actually looking for. Like something's >> not completing there that should be so that those files are >> decompressed and then magically manipulated together to become what's >> housed in the /var/lib/apt/lists parent directory... :) >> > > Thanks to all three for very helpful replies. > > Unfortunately Elimar's suggestion only partially helped; it did not > clear /var/lib/apt/lists/partial, although running apt-get update did > clear it. It then soon started filling up again. > > It would appear that apt-get update is being run automatically; I'm > happy for it to do so, provided it works properly. > > Running apt-get update manually showed an error: > Err http://ftp.uk.debian.org jessie-backports/non-free amd64 Packages > and the directory started filling. > > I've now commented out the lines in sources.list referring to > jesie-backports, and running apt-get update doesn't seem to fill that > directory. I'll have to monitor that one! > > My conclusion, if the mod fixes it, is that (a) that repository is > broken in some way, and (b) apt contains a bug allowing it to misbehave > under error conditions. > > I shall only be at the end of a wet piece of string for my internet > connection for the next week, so may not be able to progress this as > much as I would like for a while. > > Thanks again, Tony >
For the sake of the archives, here is the latest situation. Having not had the /var partition fill for several days, I re-enables jeaaie-backports in my sources.list, and ran apt-get update. No errors, and no entries in /var/lib/apt/lists/partial. So, I guess it was the mirror at ftp.uk.debian.org that was broken, and it's now been fixed. Is there anywhere I can look to confirm this? cheers, -- Tony van der Hoff | mailto:t...@vanderhoff.org Buckinghamshire, England |