handle mysql process crashes gracefully
Review Request #129264 - Created Oct. 26, 2016 and submitted
It happened to me that I started kmail but could not see any mail folder.
Searching I found that although all akonadi processes were running, the mysqld process was not,
so it seems for whatever reason mysqld crashed (using a privately started mysqld from akonadiserver).
This patch checks if the mysqld stops unexpectedly when it was started from akonadiserver and tells the latter to quit when a stopped mysqld was discovered.
Also in this case the local socket file is removed so that a restart can work without problem.
Started akonadi via akonadictl and also implicitely via kmail, then killed (-4, -15) mysqld.
Restarted via akonadictl or kmail
|Either this has to stay here, or stopInternalServer() must be adjusted to not just give up when mDatabaseProcess is null, ...||Daniel Vrátil|
Looks like a good start, just fix the style issue and we can ship it.
It would be nice if we could also handle the second case and that's system crash (i.e. when Akonadi won't be able to perform this cleanup). The startup code should check for the socket file and the .PID file in db_data, check if the process with such PID exists and if its MySQL. Then either connect to it right away, or clean up the socket file and the PID file before trying to start MySQL. If you are interested, you could implement this too (either as part of this patch or in a separate patch). There already is a similar code in DbConfigPostgresql::startInternalServer() that can be used for inspiration :)
looking into the "system crash" sceanrio, what about the simple following idea:
if we find a socket file, then normally the server is already running - except your above scenario.
When we now just do the "cleanup" (removal of the socket file) in the case when the "initConnection"
can not open a connection to the db, that should be enough, right ?
Revision 2 (+47 -7)
changed connect syntax.
My tests show that it is not needed to remove the .pid file (and I would not like to do that since it would
mean to deal with an implementation detail of mysql, nothing one should need to know from outside)
Revision 3 (+47 -7)
Either this has to stay here, or stopInternalServer() must be adjusted to not just give up when mDatabaseProcess is null, but still try to shutdown the DB via mCleanServerShutdownCommand.
4 spaces indent
Hmm, I'm wondering if this is maybe too brutal? What if the server is still running, just refuses our connection (for any reason)? Deleting the socket of a running server might not be a smart thing to do in that case....:-)