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

## Routine MySQL Update Successful Today

I use a system for updating my packages, which is named ‘unattended-upgrades’, and which I have blogged about before Here.

This morning, that system updated my MySQL server, which is also important to this blog, because these blog entries are in fact stored in a MySQL database. The way my blog generally works, each HTTP request causes a PHP script to be executed independently on the Apache server, and the PHP extensions I have installed, include a MySQL client. This part of the PHP scripts fetches the blog content, while other parts of the scripts format it as HTML, according to the Theme which I have chosen to install some time ago.

The individual blog entries do not actually form separate files or folders on my Web-site.

Also, it is an explicit WordPress Plug-In, which tries to retrieve the already-formed HTML from my server cache, If the HTML being requested has been cached. That Plug-In is named ‘Memcached Is Your Friend‘.

The fact that my blog still displays properly, indicates that the MySQL database is operating normally. After the upgrade, the scripts also restarted this server briefly. And, the fact that this server has been restarted, does not affect the cache, nor the speed of the blog, because the ‘memcached’ daemon is a separate process which did not receive any update or restart.

Dirk

## I have just had to get my hands dirty, with apt-listbugs.

According to This Posting, I have installed ‘unattended-upgrades‘ on the computer I name ‘Phoenix’, and I have also installed ‘apt-listbugs‘, as an insurance policy against ‘unattended-upgrades‘ auto-installing defective packages.

This has always posed the question of what will happen in practice, if ‘apt-listbugs‘ “pins” certain packages, thus having stopped them, but if the update-procedure needs to be reactivated later, manually. I have never had to act in this matter yet, while instead, there was one recorded occasion, on which upgrades did not take place on one day, but took place again a day later, automatically.

But just today I needed to override what ‘apt-listbugs‘ had done, manually. In particular, the question exists, of how one can get apt-listbugs to unpin an upgrade which was once scheduled, so that we can do the upgrade later, and so that we can see what apt-listbugs had to say about it.

By default, if we then simply type in ‘apt-get upgrade‘, nothing happens.

As it turns out, there is a single file named ‘/etc/apt/preferences.d/apt-listbugs‘, which we need to delete, before we can restart an upgrade process.

After I did this, my ‘apt-get upgrade‘ took place normally again, and I got to see what the error was, over which ‘apt-listbugs‘ had stopped the unattended upgrade today.

Dirk