Quoting Cindy-Sue Causey (butterflyby...@gmail.com): > On 9/4/15, Tony van der Hoff <t...@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.