Re: /var/lib/apt/lists/partial fills entire partition [SOLVED]
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 <riesebie@lxtec.de> wrote:
>>> * Tony van der Hoff <tony@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:tony@vanderhoff.org
Buckinghamshire, England |
Reply to: