Faustin Lammler added a comment - 2020-04-10 14:15 otto thanks for looking deeply into this! I agree with most your solution proposal. But I believe this one is not totally correct: > systemctl aliases are good, they increase compatibility with mysql - skipping them to "fix" this bug is the wrong tradeoff Aliases is not the best solution to increase compatibility with mysql. Instead, "shipping a (static) symlink in the package is the second best thing you can do to align the sysv init script name and the service name, The best you can do (obviously) is to use the same name for the sysv init script and the service file.", I am quoting M. Biebl, see: https://github.com/MariaDB/server/pull/1172#discussion_r305863850

Otto Kekäläinen added a comment - 2020-04-10 14:25 - edited They are called aliases also when they are implemented via symlinks. I have been testing with a recent Debian Sid environment and I am actually at the moment unable to reproduce the original bug. Seems like the `/lib/lsb/init-functions` which ends up calling `/lib/lsb/init-functions.d/40-systemd` handles this correctly already. Sources at https://sources.debian.org/src/systemd/245.4-4/debian/extra/init-functions.d/40-systemd/

Otto Kekäläinen added a comment - 2020-05-17 09:54 faust Just to be sure, can you please test that latest 10.5 surely does not suffer from this issue anymore? And if there is some corner case where it does suffer, then document how to reproduce that.

Faustin Lammler added a comment - 2020-05-21 10:07 Hi otto ! I have tested the latest upstream version (10.5.4) against buster and sid. I am not able to reproduce the issue, and synchronization (between sysvinit and systemd) seems very sane to me, also disable works (and persists after reboot) in both cases (mariadb or mysql). The unique "not so sane" but not problematic scenario is the following (change on /etc are tracked with etckeeper ): $ cd /etc $ sudo apt install etckeeper $ sudo systemctl disable mariadb $ sudo git status On branch master Changes not staged for commit: (use "git add/rm <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) deleted: rc2.d/S01mariadb deleted: rc3.d/S01mariadb deleted: rc4.d/S01mariadb deleted: rc5.d/S01mariadb deleted: systemd/system/multi-user.target.wants/mariadb.service   Untracked files: (use "git add <file>..." to include in what will be committed) rc2.d/K01mariadb rc3.d/K01mariadb rc4.d/K01mariadb rc5.d/K01mariadb $ sudo systemctl enable mysql On branch master Changes not staged for commit: (use "git add/rm <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) deleted: rc2.d/S01mariadb deleted: rc3.d/S01mariadb deleted: rc4.d/S01mariadb deleted: rc5.d/S01mariadb   Untracked files: (use "git add <file>..." to include in what will be committed) rc2.d/K01mariadb rc3.d/K01mariadb rc4.d/K01mariadb rc5.d/K01mariadb $ sudo reboot $ sudo systemctl status mariadb ● mariadb.service - MariaDB 10.5.4 database server Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: enabled) Drop-In: /etc/systemd/system/mariadb.service.d └─migrated-from-my.cnf-settings.conf Active: active (running) since Thu 2020-05-21 11:34:42 CEST; 25min ago ... Systemd is starting mariadb even if sysv runlevel files were not synchronized by systemctl enable mysql . But this is a already known behavior ( https://github.com/systemd/systemd/issues/15394 ).

Otto Kekäläinen added a comment - 2020-05-21 19:52 Thanks for verifying we are all good now. Since in systemd the 'mysql' is a alias for 'mariadb', it is correct that 'sudo systemctl enable mysql' will enable MariaDB and MariaDB will be running after the next reboot. It does not matter what state the rcXd./XXmariadb files are in, since if the system has systemd (and systemctl), it will do what systemd says ignoring rcXd./XXmariadb status.