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.
This would be my best guess, as to why the earlier attempt failed:
The earlier situation updated the processes which run in user-space, as part of the session, specifically Akonadi. When the session is told to quit, a lengthy process takes place where Akonadi first tries to save all its data to the HD, before exiting in fact.
The earlier update could have been such, that configuration specifics did not permit this to happen, even though that new configuration was consistent enough with itself, that a new Akonadi session would run without problems. Thus, it must have been the transition which was troublesome then, from an old software-version with access to a new configuration, to the new software-version, for which the new configuration was also written.