[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


Reply to: