Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #157280 > unrolled thread

/var/lib/apt/lists/partial fills entire partition

Back to article view | Back to linux.debian.user

Contents

  /var/lib/apt/lists/partial fills entire partition Tony van der Hoff <tony@vanderhoff.org> - 2015-09-01 14:20 +0200
    Re: /var/lib/apt/lists/partial fills entire partition Elimar Riesebieter <riesebie@lxtec.de> - 2015-09-01 14:40 +0200
      Re: /var/lib/apt/lists/partial fills entire partition David Wright <deblis@lionunicorn.co.uk> - 2015-09-01 16:30 +0200
      Re: /var/lib/apt/lists/partial fills entire partition Cindy-Sue Causey <butterflybytes@gmail.com> - 2015-09-01 16:50 +0200
        Re: /var/lib/apt/lists/partial fills entire partition Tony van der Hoff <tony@vanderhoff.org> - 2015-09-01 17:50 +0200
          Re: /var/lib/apt/lists/partial fills entire partition Elimar Riesebieter <riesebie@lxtec.de> - 2015-09-01 18:10 +0200
          Re: /var/lib/apt/lists/partial fills entire partition [SOLVED] Tony van der Hoff <tony@vanderhoff.org> - 2015-09-04 12:20 +0200
            Re: /var/lib/apt/lists/partial fills entire partition [SOLVED] Cindy-Sue Causey <butterflybytes@gmail.com> - 2015-09-04 22:10 +0200
              Re: /var/lib/apt/lists/partial fills entire partition [SOLVED] Cindy-Sue Causey <butterflybytes@gmail.com> - 2015-09-05 01:30 +0200
              automating apt-get, was Re: /var/lib/apt/lists/partial fills entire  partition David Wright <deblis@lionunicorn.co.uk> - 2015-09-05 03:40 +0200

#157280 — /var/lib/apt/lists/partial fills entire partition

[Multipart message — attachments visible in raw view] — view raw

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?

-- 
Tony van der Hoff        | mailto:tony@vanderhoff.org
Buckinghamshire, England |

[toc] | [next] | [standalone]

#157281

* 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.

Elimar


-- 
 Learned men are the cisterns of knowledge,
  not the fountainheads ;-)

[toc] | [prev] | [next] | [standalone]

#157292

Quoting Elimar Riesebieter (riesebie@lxtec.de):
> * 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?

I don't have any answer to this, only questions.

Presumably   ls -lt   tells you when these files were created. Is this
periodic, and is this because you have automated apt-get update?

If you run   apt-get update   manually, do you get errors? After doing
that, is there a new tranche of files? Or are there any fewer?
The .decomp. names suggest decompression has taken place and these are
the output files. Perhaps decompression is failing and setting a
return code preventing further treatment.

> 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.

Unfortunately,   apt-get clean   cleans the *cache*, not the lists.
But in any case, best not wipe away the symptoms without looking for
a cause first as there may be clues in the files' properties.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#157296

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... :)

-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs... behind an ~80-year-old push reel mower *

[toc] | [prev] | [next] | [standalone]

#157297

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



-- 
Tony van der Hoff        | mailto:tony@vanderhoff.org
Buckinghamshire, England |

[toc] | [prev] | [next] | [standalone]

#157302

* Tony van der Hoff <tony@vanderhoff.org> [2015-09-01 17:47 +0200]:

[...] 
[...]
> 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.

deb http://ftp.de.debian.org/debian jessie-backports non-free

works flawlesly here.

Elimar
-- 
 Never make anything simple and efficient when a way
  can be found to make it complex and wonderful ;-)

[toc] | [prev] | [next] | [standalone]

#157395 — 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 |

[toc] | [prev] | [next] | [standalone]

#157405 — Re: /var/lib/apt/lists/partial fills entire partition [SOLVED]

On 9/4/15, Tony van der Hoff <tony@vanderhoff.org> wrote:
> On 01/09/15 17:47, Tony van der Hoff wrote:
>>
>> 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?


I'm sorry I missed that next email of yours. This is another of those
areas that's outside my self-taught knowledge but am going to comment
anyway. I, too, like the automatic option for something like that,
especially if you have an Internet connection with the capacity to
handle it. Meaning not like mine where I have to cherry pick what's
all running at the same time. That 967 BYTES per second I referenced
the other day was no joke. I've just never been fast enough to
printscreen it when it appears on the terminal.

Related to your previous reply about "provided it works properly",
maybe someone here with the knowledge of how it's done can tip you on
setting up a report that's automatically generated when update runs.
That's surely a possibility, and that way you'd be getting a heads up
should anything like this come up again for you.

At least I THINK a report could be generated since I've seen past
threads about similar. The threads just completely went over my head
at the time outside of mentally toggling that learning experience as a
future *to do*....

Cindy :)

-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs... outside *to do* daily chores that never seem *to do* themselves *

[toc] | [prev] | [next] | [standalone]

#157409 — Re: /var/lib/apt/lists/partial fills entire partition [SOLVED]

On 9/4/15, Cindy-Sue Causey <butterflybytes@gmail.com> wrote:
>
> Related to your previous reply about "provided it works properly",
> maybe someone here with the knowledge of how it's done can tip you on
> setting up a report that's automatically generated when update runs.
> That's surely a possibility, and that way you'd be getting a heads up
> should anything like this come up again for you.
>
> At least I THINK a report could be generated since I've seen past
> threads about similar. The threads just completely went over my head
> at the time outside of mentally toggling that learning experience as a
> future *to do*....


Some lightning started striking outside so I came inside to play.. on
the laptop. Got to thinking on it. "Cron job" kept coming to mind
before so I searched on it. Feedback I'm getting is that's about
"timed" jobs being set up.

In starting a new search, the search engine's autocomplete related to
"how do i"/"activity based job" suggested "incron" so I took the bait.
Kind of sounds promising but I'm *cognitively* not digesting it well
enough to suggest something to try right now:

https://www.debian-administration.org/article/581/Running_programs_when_filesystem_events_occur

I downloaded it and it was TINY, something like only 67KB when its
dependencies are already in place. Maybe someone else already has
experience with it and can help with personally garnered do's or
don'ts? Or maybe has a "no, not quite that but maybe try this"?

Good luck!

Cindy :)

-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* might need an incron job to trigger doing daily chores *

[toc] | [prev] | [next] | [standalone]

#157411 — automating apt-get, was Re: /var/lib/apt/lists/partial fills entire partition

Quoting Cindy-Sue Causey (butterflybytes@gmail.com):
> On 9/4/15, Tony van der Hoff <tony@vanderhoff.org> wrote:
> > On 01/09/15 17:47, Tony van der Hoff wrote:
> >>
> >> 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?
> 
> 
> I'm sorry I missed that next email of yours. This is another of those
> areas that's outside my self-taught knowledge but am going to comment
> anyway. I, too, like the automatic option for something like that,
> especially if you have an Internet connection with the capacity to
> handle it. Meaning not like mine where I have to cherry pick what's
> all running at the same time. That 967 BYTES per second I referenced
> the other day was no joke. I've just never been fast enough to
> printscreen it when it appears on the terminal.
> 
> Related to your previous reply about "provided it works properly",
> maybe someone here with the knowledge of how it's done can tip you on
> setting up a report that's automatically generated when update runs.
> That's surely a possibility, and that way you'd be getting a heads up
> should anything like this come up again for you.
> 
> At least I THINK a report could be generated since I've seen past
> threads about similar. The threads just completely went over my head
> at the time outside of mentally toggling that learning experience as a
> future *to do*....

Once again I'm having difficulty knowing whether I'm answering the
question posed, so here goes.

I could put something like
APT::Periodic::Update-Package-Lists 1;
APT::Periodic::Download-Upgradeable-Packages 1;
in /etc/apt/apt.conf but that leaves your problem of knowing when it
actually downloads anything. Rather than face the complications of
watching for files, I just stick the following in /root/crontab

MAILTO=david@localhost
# check for updated packages and provoke an email if any are in the cache
0 */3 * * * apt-get -qq update && apt-get -qq -d upgrade && find /var/cache/apt/archives/ -name '*deb'

and then run:
# crontab crontab

So if there are any files in /var/cache/apt/archives/ I get an email
listing them. When I log on I call -check-debian-updates late in my
.bash_profile

function -check-debian-updates { [ $(ls -1R /var/cache/apt/archives/ | wc -l) -eq 5 ] && return 0 || printf '%s\n' "========== There are Debian package updates available in the cache ==========" && return 1
}

This function is defined in .bashrc, hence the late call.

Obviously there's an assumption here, that I keep the cache clean.
That's because I run apt-cacher-ng on my server, and have
Acquire::http::Proxy "http://192.168.1.19:3142/";
in /etc/apt/apt.conf on every host (including the server itself).

I only *download* automatically, so root's .bash_history always has
the following lines ready for recalling:
apt-get update ; apt-get -d upgrade ; apt-get upgrade ; read -p 'Ctrl-C to avoid clean' _ ; apt-get clean
apt-get -d dist-upgrade ; apt-get dist-upgrade ; read -p 'Ctrl-C to avoid clean' _ ; apt-get clean
Obviously I only run the second one if packages are being held back.

Ignore all this if it's no help.

Cheers,
David.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web