We need the init script to maintain backward compatibility with whatever setups users have. The script is supposed to redirect to systemd.
If it causes a race condition, it needs to be fixed.

I disagree. This RPM is targeted specifically at RHEL7, which has chosen systemd as its primary service control facility. Init scripts are only supported in RHEL7 as a legacy measure to support applications that don't support systemd yet. MariaDB does support systemd, so that should be the only method necessary to package for RHEL7.

If you really need to provide an init script on RHEL7 for backwards compatibility, it should be packaged as a separate RPM like MariaDB-init so sysadmins who don't want legacy init scripts can avoid it.

This has caused me problems because the redirection is not reliable, and the systemd unit has multiple aliases. In some circumstances this causes the daemon to not start properly because the init script and systemd unit are not identical (e.g. in terms of SELinux context) and has caused a database outage at my site.

I agree with the removal of /etc/init.d/mysql. Its old, clunky and inconsistent with the init.d free nature of Centos/RHEL7. It also needs specific selinux rules to deal with mysqld_safe. Its time to let it go.

From a Centos-7.3 system with MariaDB-server-10.2 installed;

[root@dyn486 ~]# ls /etc/init.d

functions  mysql  netconsole  network  README

[root@dyn486 ~]# more /etc/init.d/README

You are looking for the traditional init scripts in /etc/rc.d/init.d,

and they are gone?

Here's an explanation on what's going on:

You are running a systemd-based OS where traditional init scripts have

been replaced by native systemd services files. Service files provide

very similar functionality to init scripts. To make use of service

files simply invoke "systemctl", which will output a list of all

currently running services (and other units). Use "systemctl

list-unit-files" to get a listing of all known unit files, including

stopped, disabled and masked ones. Use "systemctl start

foobar.service" and "systemctl stop foobar.service" to start or stop a

service, respectively. For further details, please refer to

systemctl(1).

Note that traditional init scripts continue to function on a systemd

system. An init script /etc/rc.d/init.d/foobar is implicitly mapped

into a service unit foobar.service during system initialization.

Thank you!

Further reading:

        man:systemctl(1)

        man:systemd(1)

        http://0pointer.de/blog/projects/systemd-for-admins-3.html

        http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities

Has there been any movement on this? This is still an issue for me... my systems got 10.2.11 overnight but the process that restarts the daemon after the update does so using the init script, so the systemd unit can't control the process. To regain control I have to do sudo /etc/init.d/mysql stop && sudo systemctl start mariadb.

I don't mean to be rude but it is pretty shameful that such an obvious and trivial bug still persists.

There were a few attempts to remove init script, which didn't succeed. Mainly because MariaDB RPM scripts (e.g. preun and postun) reference it.

We should probably strive for fixing this race condition first. Then we can try removing init script, not in GA version though.

elenst, I wonder if you or alice could try reproducing this race condition on our side?

You can remove the init script, because its a bug. It is a complete anti-feature in the release that is still causing problems and never belonged there. Sure the pre/post things needs fixing. Still.

svoj what about fixing pre/post scriptlets first? Then packagers will be able to exclude mysql.init script at their discretion. And in our packages we could, perhaps, move it to @sharedir@ (on systemd based distributions) instead of deleting it completely.

serg, that should work as well. I just thought that fixing race condition might be simpler and safer for 10.1.

PR #593 submitted to reflect this design.

Version 10.2 is affected :

/etc/cron.daily/0yum-daily.cron:

Shutting down MariaDB..[ OK ]
Starting MariaDB.180215 09:22:26 mysqld_safe Logging to '/var/log/mysql/mysqld.log'.
180215 09:22:26 mysqld_safe Starting mysqld daemon with databases from /data/mysql .[ OK ]
Warning: mysqld.service changed on disk. Run 'systemctl daemon-reload' to reload units.
Job for mariadb.service failed because the control process exited with error code. See "systemctl status mariadb.service" and "journalctl -xe" for details.
The following updates will be applied on srvmysql-dev.aaa.ccfa:
================================================================================
Package Architecture
Version Dépôt Taille
================================================================================
Mise à jour :
MariaDB-client x86_64 10.2.13-1.el7.centos mariadb102 48 M
MariaDB-common x86_64 10.2.13-1.el7.centos mariadb102 155 k
MariaDB-compat x86_64 10.2.13-1.el7.centos mariadb102 2.8 M
MariaDB-server x86_64 10.2.13-1.el7.centos mariadb102 110 M
MariaDB-shared x86_64 10.2.13-1.el7.centos mariadb102 394 k

Résumé de la transaction
================================================================================
Mettre à jour 5 Paquets
The updates were successfully applied

------------
2 symbolics link are created in the rpm package :
ln -s /usr/lib/systemd/system/mariadb.service /etc/systemd/system/mysql.service
ln -s /usr/lib/systemd/system/mariadb.service /etc/systemd/system/mysqld.service

But the init script has priority over the systemd script...

One of the solutions when updating packages is creating a postaction script in yum, this is bad but it's work ...

cat /etc/yum/post-actions/mysql.action
#!/bin/sh

MariaDB*:update:/usr/bin/systemctl daemon-reload && for i in `/usr/bin/ps auxf|/usr/bin/grep mysqld|/usr/bin/grep "grep" -v|/usr/bin/awk '

'`; do /usr/bin/kill -9 $i; done && rm -f /etc/init.d/mysql && /usr/bin/systemctl restart mysql

Overdue PR.