Control: retitle -1 akonadi server not robust against mysql upgrades
On Thu, 27 Apr 2023 10:32:09 +0200 Sune Stolborg Vuorela <s...@debian.org> wrote:
To me it looks like 1032047 has been fixed with a solution that makes this more likely to happen rather than list.
As far as I understand the problem (as expressed in the retitle too), I agree.
If I understand the fix correctly in that bug, it is ignoring all runnig mariadb's that is not from specific users and just upgrading anyways.That is, to my understanding, the easiest way to hit this is exactly to upgrade mariadb while it is not cleanly shutdown.
Do you have an idea what the stance of upstream is with respect to this problem? E.g. do they say "don't upgrade mysql/mariadb while logged in"? Or e.g. "stopping and later starting the mysql server should be ok". If it's the latter case, I understand (including info from bug #1032047) that the problems are: * upgrades of mysql/mariadb can't be done in place; a clean shutdown of every running mysql/mariadb server is required * there are user facing buttons that invite the user to start the akonadi backend server when it is not running; if the user session server would be killed for the upgrade, the user might (try to) start it before the upgrade is ready * mysql/mariadb lack the facilities to gracefully stop and particularly restart user session based servers
So, *if* upgrading mysql/mariadb would stop and start the user session server correctly, would there be a problem for the user if they didn't hit that button (apart from a temporary lack of service of course)? If the answer is no, are there more things to solve than:
* ensuring the user can't restart the server while it's being upgraded* ensuring that mysql and mariadb stop and restart user sessions based servers (in a policy compliant way)
Paul
OpenPGP_signature.asc
Description: OpenPGP digital signature
