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

## My Unattended Upgrades took place normally again.

The Unattended Upgrades process, which did not seem to complete yesterday morning, March 14, resumed completing normally today, even though this time, there were simply no upgrades to install. This tells me that having performed no configuration changes on my part, did not prevent the service from resuming, and that the interruption was due to something transient.

## Unattended Upgrades Did Not Run This Morning.

I previously wrote about the Debian package ‘unattended-upgrades’ Here. This morning however, this system did not install any upgrades, almost as if it had not run. Yet, I found no changes to any of the relevant configuration files. But I do have a tentative explanation as to why, maybe, this package did not run as usual.

When I prompted my KDE desktop tool to do the pending upgrades – that tool having been named “Tasker” in some versions of KDE, it showed that there was an upgrade pending for the package “Wireshark”. What I dimly seem to recall, is that the previous version of Wireshark had a severe bug. It is entirely possible that the unattended upgrades did not run this time, because I also have installed ‘apt-listbugs’.

If this supposition was true, then today would have been the first demonstration, of how this package will prevent an unattended upgrade from running. If true, this would come as a relief, because I previously had the fear that although this package would prevent a potentially damaging upgrade, it might also corrupt the state of ‘apt-get’. Apparently it will not. Let us keep our fingers crossed.

Dirk