Routine Desktop Session Restart

According to This Earlier Posting, the ‘unattended-upgrades‘ package updated a whole slew of MySQL packages this morning, that of course form the most important database engine on this machine (‘Phoenix’). As an automated part of the process, the update restarted the MySQL Server process, which runs as a system service.

However, the way KDE works, it has an Akonadi Server for ‘PIM’ (Personal Information Management), which runs its own, local MySQL database engine, as part of the user session, which is of course not restarted automatically, because to do so would also interfere strongly with a running session.

And yet, this latter process can also be brought up-to-date, by just logging out the (graphical) desktop session, and logging back in again. Doing so should not affect any of the system processes, which either run as ‘root‘, or which run as a vestigial, system user-name. Likewise, doing so should not affect the Web-server.

Hence, to bring my session up-to-speed, I performed this logout / login successfully and without ado, which actually took from 15h15 until 15h25.

Yet, there was An Earlier Situation, in which an attempt to do the same thing went wrong.

Continue reading Routine Desktop Session Restart

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

 

The Blog will be a little slow for the next few hours or day…

In the way I have set up WordPress.org, it makes use of a caching daemon named ‘Memcached‘, that runs on my server and speeds up the fetching of specific, frequently-requested content. This is not to be confused with whatever cache is also speeding up your browser.

As part of a routine set of updates fed through my package manager this evening, this daemon also received an update, which required that it be restarted. As a result, the cache is now cleared, and the fetching of the favorite postings to the readers will be somewhat slow for the next few hours, or maybe even for a whole day.

I apologize if this inconveniences anybody.

Also, this behavior does not represent any sort of malfunction, either by the daemon, nor in the update process. All the updates seemed to go through just fine.

Dirk