Bug #88463 Add service notification via socket
Submitted: 13 Nov 2017 14:33 Modified: 22 Mar 2018 17:33
Reporter: Terje Røsten Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Compiling Severity:S3 (Non-critical)
Version:8.0.4 OS:Any
Assigned to: CPU Architecture:Any

[13 Nov 2017 14:33] Terje Røsten
Description:
Support for running mysqld under systemd was improved in MySQL 5.7 by introducing new --daemonize option to mysqld. This option is also useful for SysV init systems. 

However, it was discovered that behaviour in case of error was somewhat weak. 

This is due to systemd's limited capability to follow a double forked process 
(Type=forking in service file) as the only reliable interface is a pidfile.
For example is the statement RestartPreventExitStatus=1 ignored by systemd due to 
this limitation. 

A better, more robust method is keep mysqld process in foreground and signal back
to systemd when mysqld is ready for connections (Type=notify). 
This is done by writing READY=1 to socket at $NOTIFY_SOCKET at the correct time
during start up.
It's also of interest to send other messages to systemd, see: 
http://0pointer.de/public/systemd-man/sd_notify.html
for the full list and more information.

How to repeat:
Run mysqld under systemd with --daemonize and make mysqld exit with error 1:
process is still restarted.

Suggested fix:
Add systemd notification support to mysqld.
[22 Mar 2018 17:33] Paul DuBois
Posted by developer:
 
Fixed in 8.0.11.

For platforms that use systemd, systemd was not always able to infer
the state of a double-forked mysqld process. Consequently, systemd
would attempt to restart mysqld even when that process terminated
with status 1. systemd is now configured to run mysqld as a normal
process (Type=notify rather than Type=forking). If the name of a
socket file is specified in the environment variable NOTIFY_SOCKET,
mysqld attempts to open a connection for communicating with systemd
and writes its state changes there.