chrisbell at chrisbell.org.uk
Mon Feb 18 11:51:11 UTC 2019
On Monday, 18 February 2019 08:49:03 GMT John Winters via GLLUG wrote:
> On 17/02/2019 17:27, Chris Bell via GLLUG wrote:
> > Hello,
> > I have a computer running KDE on Debian Stretch that will usually not
> > allow
> > aptitude to "u" (update the list of available packages) because
> > /var/lib/apt/ lists/lock is open. I can delete the lock and then "u",
> > sometimes finding that lists were not already up to date. It is one of
> > three computers running Apt- Cacher NG which could be locking the lists,
> > two with KDE while the third is not running a desktop, but only one shows
> > the problem.
> > Any suggestions why? Thanks.
> You missed out the crucial information - which one is showing the problem?
I am running Apt- Cacher NG on the firewall, mainly for RaspberryPi units in
the DMZ, there is no desktop. No problems.
I have one box running KDE and Apt- Cacher NG which has given previous
Another box runs KDE, Apt- Cacher NG mainly for security updates, and a
partial Debian mirror which is updated overnight using ftpsync, although that
should not need to touch /var/lib/apt/lists/. The current lock shows it was
created 14.29 on 3rd February, so not recent or overnight. Something is
creating the lock but not clearing it, so that is probably when I last deleted
it. KDE does sometimes flag that an update is available, yet if I remove the
lock I sometimes find that there are important updates available that had not
been flagged. This is usually just after I had updated other computers.
> P.S. Pet hate - the latest idea that because Windows can't manage
> updates without a re-boot, now Linux has to do a re-boot too. Uuugh!
Debian does not always require a re-boot, although individual packages may
still require a configuration re-load. I normally use aptitude, and carefully
watch its progress for any re-boot requests, usually when there is a major
More information about the GLLUG