Posting the issue here as suggested by serg on IRC
In reference to Gentoo Bug 461226,
MariaDB holds open stdin after being started like this example:
{noformat}
start-stop-daemon --background --exec /usr/sbin/mysqld -- --defaults-file=/etc/mysql/my.cnf
{noformat}
Posting the issue here as suggested by serg on IRC
My suggestion was to implement a very old and popular request and let mysqld to daemonize itself. Additionally, if it'll do that only after it is ready to accept new connections it will also remove the need for hacks like Fedora's mysql-wait-ready script that runs mysqladmin ping in a loop to detect when a server is finally ready to serve (meaning, systemd can start services that depend on mysqld).
Sergei Golubchik
added a comment - My suggestion was to implement a very old and popular request and let mysqld to daemonize itself. Additionally, if it'll do that only after it is ready to accept new connections it will also remove the need for hacks like Fedora's mysql-wait-ready script that runs mysqladmin ping in a loop to detect when a server is finally ready to serve (meaning, systemd can start services that depend on mysqld).
There's one difficulty with daemonizing — if mysqld will simply fork and exit when it's ready to accept connections, it will change the pid of the mysqld daemon process. And by that time the pid is already written into the pidfile. Creating the pidfile later is not a good idea, currently it's created as soon as the signal handler is installed, that is, as soon as mysqld can process signals sent to this pid. Rewriting pidfile to put a new pid in it could work, but I don't know what it might possibly break. A safe solution might be to fork early but make the parent process wait until the child is ready to accept connections.
Sergei Golubchik
added a comment - There's one difficulty with daemonizing — if mysqld will simply fork and exit when it's ready to accept connections, it will change the pid of the mysqld daemon process. And by that time the pid is already written into the pidfile. Creating the pidfile later is not a good idea, currently it's created as soon as the signal handler is installed, that is, as soon as mysqld can process signals sent to this pid. Rewriting pidfile to put a new pid in it could work, but I don't know what it might possibly break. A safe solution might be to fork early but make the parent process wait until the child is ready to accept connections.
With systemd coming along and it generally works better without daemonizing as it relying on sigchild is heaps more repliable than fiddling with pid files, this bug can be fixed by doing the minimal approach and just close the stdin after the checking we aren't doing a bootstrap.
Daniel Black
added a comment - With systemd coming along and it generally works better without daemonizing as it relying on sigchild is heaps more repliable than fiddling with pid files, this bug can be fixed by doing the minimal approach and just close the stdin after the checking we aren't doing a bootstrap.
I just got a query from ALTLinux maintainers. They're interested in "daemonize" option, the reasons are:
compatibility with MySQL 5.7 (it has this option too)
most server binaries (e.g. sshd) have ability to daemonize
simplified SysV scripts
no need for extra overcomplicated wrappers (like mysqld_safe)
Sergey Vojtovich
added a comment - I just got a query from ALTLinux maintainers. They're interested in "daemonize" option, the reasons are:
compatibility with MySQL 5.7 (it has this option too)
most server binaries (e.g. sshd) have ability to daemonize
simplified SysV scripts
no need for extra overcomplicated wrappers (like mysqld_safe)
My suggestion was to implement a very old and popular request and let mysqld to daemonize itself. Additionally, if it'll do that only after it is ready to accept new connections it will also remove the need for hacks like Fedora's mysql-wait-ready script that runs mysqladmin ping in a loop to detect when a server is finally ready to serve (meaning, systemd can start services that depend on mysqld).