This was re-examined moderately recently in MDEV-10382.

The criteria of abort is an unclean signal. The handling on these signal is covered in https://github.com/MariaDB/server/blob/10.1/sql/mysqld.cc#L3279..L3305 (SIGHUP, SIGINT, SIGTERM or SIGPIPE) some are ignored and the rest end up in https://github.com/MariaDB/server/blob/10.1/sql/mysqld.cc#L1805 (kill_mysql). Here the signals are never re-raised.

The mysql signal handling is significantly different and seems, though I'm not 100% sure, to raise signals within the hander to achieve a usable Restart=abort.

Based on the Restart table in https://www.freedesktop.org/software/systemd/man/systemd.service.html the additional criteria covered by on-failure over abort is:

• Unclean exit code
• Timeout
• Watchdog

Watchdog(s) aren't configured. Timeouts can be an issue MDEV-9202. Unclean signals never hit systemd (though this was my preference in MDEV-10382) therefore mariadb relies on the Unclean exit code for stopping a service and requires on-failure.

Consider using mariadb-service-convert in your packaging to create a systemd config file from a users non-systemd my.cnf file.

I just read https://mariadb.com/kb/en/mariadb/systemd/

We are going to have some problems here as the /etc/mysql/my.cnf is pretty much empty in Debian. All configs are in /etc/mysql/mariadb.cnf.d/* or /etc/mysql/mysql.cnf.d

/etc/mysql/

/etc/mysql/mariadb.conf.d

/etc/mysql/mariadb.conf.d/50-server.cnf

/etc/mysql/mariadb.conf.d/50-mysqld_safe.cnf

/etc/mysql/mariadb.conf.d/50-mysql-clients.cnf

/etc/mysql/mariadb.conf.d/50-client.cnf

/etc/mysql/debian-start

/etc/mysql/my.cnf.fallback

/etc/mysql/my.cnf

/etc/mysql/mariadb.cnf

/etc/mysql/conf.d

/etc/mysql/conf.d/mysql.cnf

/etc/mysql/conf.d/mysqldump.cnf

/etc/mysql/debian.cnf

The mysqld_safe options are maybe in /etc/mysql/mariadb.conf.d/50-mysqld_safe.cnf but they could be in other files too. I conversion that only reads /etc/mysql/my.cnf is not going to work.

The old init file also has a section where it read the /etc/default/mariadb file to adjust timeouts etc. Now systemd does not seem to support that.

Also the assumption in the mariadb@.service to read /etc/my.cnf.d/my%I.cnf is not going to work as such.

I wonder what I should do about these. I only have 1 day to fix this..

FWICS MariaDB already has on-abort. Fix for MDEV-10382 does signal re-raise, so it is pretty much inline with on-abort.

I don't see any value in RuntimeDirectory as soon as it stays unused.

Conversion script does /usr/bin/mysqld_safe --dry-run so it should read anything that mysqld_safe would normally read.

I'm not completely sure regarding /etc/default/mariadb. Isn't it deprecated way of setting things with systemd? I believe EnvironmentFile might help.

Do you really need multi-instance config in Debian? I believe it was there mostly for reference and wasn't supposed to work out of box.

> FWICS MariaDB already has on-abort. Fix for MDEV-10382 does signal re-raise, so it is pretty much inline with on-abort.

Ah cool. This will also solve your timeout issue as there is no timeout without on-abort. Using the systemd way of doing timeouts will make a consistent sysadmin interface with systemd.

> I'm not completely sure regarding /etc/default/mariadb. Isn't it deprecated way of setting things with systemd? I believe EnvironmentFile might help.

I agree, sounds like a depreciated way and really clunky to port in its current namer.

> Do you really need multi-instance config in Debian? I believe it was there mostly for reference and wasn't supposed to work out of box.

I wrote it mainly as a reference and doesn't expect it to be enabled usually. Changing the mariadb@.service to read /etc/my.%I.cnf might be one step closer to out of the box ready.

Inspired by the above I made these changes:

• https://github.com/ottok/mariadb-10.1/commit/3ff2bdd742d16e1289e68bd19eefe6e3b4c7e2d5
• https://github.com/ottok/mariadb-10.1/commit/ccc01d88a56cdae2b467be5d74bb810476a6603f

It does not fix any problems, but at least it should make it faster for sysadmins to debug what happened if they run into problems.

danblack /etc/my.%I.cnf would be an improvement, but ideal would maybe be /etc/mariadb.%I.cnf

Looks good. Something upstream based on INSTALL_SYSCONFDIR/mariadb.%I.cnf would probably be idea.

running ```mariadb-service-convert > /etc/systemd/system/mariadb.service.d/migrated-from-my.cnf-settings.conf``` covers a lot of the common cases where sysadmin have changed mysqld_safe settings.

I am not quite sure I understand how this mariadb-service-convert behaves on installs and upgrades.

In upstream mariadb.org 10.1.x the mariadb-server-10.1.files always install the file etc/mysql/conf.d/mysqld_safe_syslog.cnf. If the orignal one was not modified or did not exists, all installations end up with the same config.

Then the postinst always runs this:

    # copy out any mysqld_safe settings

    systemd_conf=/etc/systemd/system/mariadb.service.d/migrated-from-my.cnf-settings.conf

    if [ -x /usr/bin/mariadb-service-convert -a ! -f "${systemd_conf}" ]; then

      mkdir -p /etc/systemd/system/mariadb.service.d

      /usr/bin/mariadb-service-convert > "${systemd_conf}"

    fi

So all installs end up having a migrated-from-my.cnf-settings.conf file? We want the migration file to exists only on old installs, and fresh installs should use the systemd defaults, right?

I am planning to not run the mariadb-service-convert automatically, and instead rely on the fact that since I changed the config file, people ugrading will see the dialog:

Configuration file '/etc/mysql/mariadb.conf.d/50-mysqld_safe.cnf'

 ==> Modified (by you or by a script) since installation.

 ==> Package distributor has shipped an updated version.

   What would you like to do about it ?  Your options are:

    Y or I  : install the package maintainer's version

    N or O  : keep your currently-installed version

      D     : show the differences between the versions

      Z     : start a shell to examine the situation

 The default action is to keep your current version.

*** 50-mysqld_safe.cnf (Y/I/N/O/D/Z) [default=N] ? 

..and thus take actions to recover their setting if needed, otherwise MariaDB systemd will run with detaults (which I assume are better than any legacy setting carried over).

People may choose to change mysqld_safe settings that aren't in /etc/mysql/mariadb.conf.d/50-mysqld_safe.cnf

I think the postinst should be kept. These will migrate existing explicit settings of mysqld_safe to a systemd equivalent.

Particularly important is LimitNOFILE/open_files which is 16K by default however a user installation could easily have a higher limit set. An explicit timezone will also need to be migrated to keep the behaviour of MariaDB the same. The other settings are probably less critical however they are only migrated if explicitly set.

Why install mariadb.conf.d/50-mysqld_safe.cnf anyway since it isn't ever used with systemd as no mysqld_safe section is read?

My point was that with current postinst script in upstream MariaDB 10.2 etc sources, everybody will end up with a /etc/systemd/system/mariadb.service.d/migrated-from-my.cnf-settings.conf, even on completely fresh installs. Wasn't this supposed to be just a fall-back? New installs we want to have using systemd defaults instead, right?

Yes the script is intended to be upgrade from non-systemd version only (at least covered by -f "${systemd_conf}") or migration from MySQL

Restart=on-abort covered in 6346d1de2fda

Seems like https://github.com/ottok/mariadb-10.1/blame/master/support-files/mariadb.service.in contains exactly the mariadb version.

Multi-instance fixes are in https://github.com/MariaDB/server/pull/510 for 10.3

I don't have a good solution mariadb-service-convert to only run on non-systemd converts.

Anything else that needs to be covered to close this?

all seems to be fixed in MDEV-10382