All my desktop and laptop computers are Linux-based, more specifically, being Debian-based, but I enjoy having some of the simplifications which Windows offers, including either to notify me of pending updates, so that I can use point-and-click methods to install those, or even, in some cases, to install updates automatically. The package which I use, to install updates automatically, as I sleep, is called ‘unattended-upgrades’, which is a package which cannot simply be installed and forgotten. If the user has installed this package, he or she must also configure it. And the following Web-article explains, how to do so under Debian:

A situation I was having for some time was, that ‘unattended-upgrades’ was installed and working fine, on my Debian / Jessie – aka Debian 8 computer named ‘Phoenix’, but that even though I had followed all the instructions for how to install and configure it on my Debian / Stretch – aka Debian 9 computer named ‘Phosphene’, the same package did not seem to work on that one. I had often found that if there did exist updates which the automated process was supposed to install, then the log file on ‘Phosphene’ would break off, just before indicating which packages were going to be installed, and no updates would take place. This would happen every time that some updates were to be installed, and required each time, that I install the updates in question manually. Also, the ‘normal’ logging output did not include any error messages; it would simply stop in mid-process.

What I finally needed to do in order to troubleshoot this process, was to wait until there were going to be pending updates, and then, instead of installing those manually, to run the following command from the command-line, as root, and to observe the output:





Running this command when there were no updates pending was rather useless, because the malfunction would not take place, unless there were updates pending. Also, this process should not be interrupted if it’s in the middle of installing updates, because doing so can and will cause package-corruption and / or software corruption. If the process is going to install multiple packages, the user needs to wait until that process has finished, before doing anything else from the same command-line. What I finally found was, that the article linked to above omits a very important piece of information.

## Latest Debian Security Update Breaks Jessie (Resolved).

In addition to my Debian / Stretch computer, I still operate two Debian / Jessie computers. Those latter two computers were subscribed to the Debian Security repository, as well as to the standard Debian / Jessie repository. Unfortunately, the package manager on one of my Debian / Jessie computers had made me aware of a conflict which existed, due to an update which Debian Security is pushing, to a package and its related packages, all belonging to:

liqt4-dev

The version which Debian Security is trying to install is:

4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u2

But, the version which the rest of Debian / Jessie was using, was:

4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1

The problem was the fact that, if I told my package manager to go ahead with its suggested updates, doing so would have forced me to reject a long, long list of packages essential to my system, including many KDE-4-related packages. Now, I can just ignore that this problem exists, and rely on my package manager again not installing packages, that would break my system, on a daily basis. But this would turn into a very unsafe practice in the long run. And so, the only safe course of action for me currently seemed to be, to unsubscribe from Debian / Security instead.

(Update 17h55 : )

I have resubscribed to the Debian Security repository in question, and re-attempted the update, to find that this time, it worked. I can think of 2 possible reasons why it might not have worked the first time:

1. My unattended-upgrades script is configured to break up an update into smaller pieces, and because this update involves a large number (over 20) of Qt 4 packages, this in itself could have broken the ability to perform the update, or
2. Debian Security may not have put all the involved updates ‘out there’ on its servers, to be downloadable in one shot, even though every Qt 4 package needs to be updated, in order for any of the updates to succeed. But, only hours later, all the required packages may have become available (on the servers).

I rather think that it was due to reason (2) and not reason (1) above.

Dirk

## Unattended Upgrades Resumed Running Normally Again, This Morning.

In This earlier posting only yesterday, I had written that for an unknown reason, my unattended upgrades not only did not run automatically, but that the responsible ‘cron.daily‘ script refused to run them, when invoked manually as root.

Well today, the unattended upgrades ran normally again, and also installed numerous updates. Routinely, without apparent errors.

Dirk

## Unattended Upgrades Did Not Run This Morning.

I have had the strange experience, that this morning, for reasons unknown, my unattended upgrades system did not run, not even leaving an entry in any of its log files.

Additionally, running the script manually as root:


/etc/cron.daily/apt




Simply reproduces the behavior, of the updates not running.

But, I have noticed that This has happened to me once before. Strangely, the last time this happened was on March 14, 2016. This is usually around the time of year that Daylight Savings Time begins, and DST began this past Sunday, which was yesterday.

If this is somehow a DST bug, then I find it most strange, that it would not affect the Sunday in question, but the following Monday.

I will continue to monitor this problem. In 2016, the malfunction simply evaporated by the next day.

(Edit 03/14/2017 : )