No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 9.2 (stretch)
Release: 9.2
Codename: stretch

The issue can be reproduced has follows:

1. Start the mariadb service:

root@srv01:~# systemctl start mariadb

2. Check that the service is running:

root@srv01:~# systemctl status mariadb

● mariadb.service - MariaDB database server

   Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: enabled)

   Active: active (running) since Sun 2018-01-14 22:07:30 UTC; 20s ago

  Process: 17865 ExecStartPost=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)

  Process: 17862 ExecStartPost=/etc/mysql/debian-start (code=exited, status=0/SUCCESS)

  Process: 17644 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR= ||   VAR=`/usr/bin/galera_recovery`; [ $? -eq 0 ]   && systemctl set-environment _WSREP_START_POSITION=$VAR || exit 1 (code=exit

  Process: 17640 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)

  Process: 17637 ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d /var/run/mysqld (code=exited, status=0/SUCCESS)

 Main PID: 17834 (mysqld)

   Status: "Taking your SQL requests now..."

    Tasks: 29 (limit: 4915)

   CGroup: /system.slice/mariadb.service

           └─17834 /usr/sbin/mysqld

Jan 14 22:07:27 srv01 systemd[1]: Starting MariaDB database server...

Jan 14 22:07:28 srv01 mysqld[17834]: 2018-01-14 22:07:28 140228024779328 [Note] /usr/sbin/mysqld (mysqld 10.1.26-MariaDB-0+deb9u1) starting as process 17834 ...

Jan 14 22:07:30 srv01 systemd[1]: Started MariaDB database server.

3. Enable the mariadb service unit. This is what our installation script is doing to ensure that the service is enabled. Basicallyn it resolves the aliased mysql unit to the real mariadb.service unit and enable it):

root@srv01:~# systemctl enable mariadb

4. Check status of aliased service units:

root@srv01:~# systemctl is-active mysql mysqld

inactive

inactive

As you can see, both are reported as inactive while we expect them reported as active.

Now the weird part:

5. Check terce status of aliased units:

root@srv01:~# systemctl status mysql mysqld

● mariadb.service - MariaDB database server

   Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: enabled)

   Active: active (running) since Sun 2018-01-14 22:07:30 UTC; 4min 18s ago

 Main PID: 17834 (mysqld)

   Status: "Taking your SQL requests now..."

   CGroup: /system.slice/mariadb.service

           └─17834 /usr/sbin/mysqld

Jan 14 22:07:27 srv01 systemd[1]: Starting MariaDB database server...

Jan 14 22:07:28 srv01 mysqld[17834]: 2018-01-14 22:07:28 140228024779328 [Note] /usr/sbin/mysqld (mysqld 10.1.26-MariaDB-0+deb9u1) starting as process 17834 ...

Jan 14 22:07:30 srv01 systemd[1]: Started MariaDB database server.

● mariadb.service - MariaDB database server

   Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: enabled)

   Active: active (running) since Sun 2018-01-14 22:07:30 UTC; 4min 18s ago

 Main PID: 17834 (mysqld)

   Status: "Taking your SQL requests now..."

   CGroup: /system.slice/mariadb.service

           └─17834 /usr/sbin/mysqld

Jan 14 22:07:27 srv01 systemd[1]: Starting MariaDB database server...

Jan 14 22:07:28 srv01 mysqld[17834]: 2018-01-14 22:07:28 140228024779328 [Note] /usr/sbin/mysqld (mysqld 10.1.26-MariaDB-0+deb9u1) starting as process 17834 ...

Jan 14 22:07:30 srv01 systemd[1]: Started MariaDB database server.

So here both are showed as active (running)
6. Again, check status of aliased units:

root@srv01:~# systemctl is-active mysql mysqld

active

active

See also: https://github.com/systemd/systemd/issues/7875

Does systemctl disable ... ever occur in your scenario? It should probably be happening at some point, if you have to run enable every time, right?

From the beginning of systemd support, we have had the problem described in MDEV-8956, which is actually an external issue, filed for Ubuntu as https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1506206 . Maybe it's related to your case.

Hey Elena,

We are providing a software (control panel for shared hosting environment management) which provides many server implementations, including a MariaDB server implementaton. On setup, the installation routines from our MariaDB server implementation make sure that the service is enabled by simply running: systemctl enable mariadb.service . See:

• https://github.com/i-MSCP/imscp/blob/hotfixes/engine/PerlLib/iMSCP/Servers/Sqld/Mariadb/Debian.pm#L56
• https://github.com/i-MSCP/imscp/blob/hotfixes/engine/PerlLib/iMSCP/Providers/Service/Systemd.pm#L90

Problem is that once you done that, the mysql.service unit, which is an alias of the mariadb.service unit will be reported as inative because not pre-loaded, and this, even if the mariadb.service is active (server running). This is a bit annoying for scripts that are relying on the mysql.service unit for compatibility purpose. Basically, an alias unit should be always reported as active if the service that define it is active. That is not the case currently. The bug has been lately confirmed by Lennart Poettering (systemd).

We solved that issue in our systemd provider by resolving the unit first (mysql.service -> mariadb.service) but. from my point of view, you should simply drop the mysql.service and mysqld.service aliases, and rename the mysql sysvinit script to mariadb. Ondřej Surý already said me that you wanted get ride of those aliases. See https://twitter.com/nuxwin/status/955536106971418624

I hope that my explanation are clear enough now.

I'm not sure that oerdnj is planning to do it in 10.1, but since Debian guys generally decide on our debian packaging issues, I'm assigning it to oerdnj to handle.

As systemd service definitions are a shared resource input from other distros is important. mschorm do you have an opinion of systemd aliases here?

FYI systemd developers have corrected the discrepancy in is-active resulting from aliases https://github.com/systemd/systemd/pull/7997

TL;DR:
I'll follow your decisions.

L;R:
In Fedora & RHEL we do use our own service files, which means, we are not directly affected, in case of a change.
We didn't provided such aliases for a long time.
However recently I was asked to add the alias to RHEL7 (bugzilla#1520577). So far I added the alias to the Fedora to let users test any side effects.

However I'm still not convinced it is the right thing to do, if somebody really wants it, they can always edit the init file. But on the other hand, I have no idea, how popular such usecase is.

—

AFAI understand, systemd fixed that, so now we only talk about a workaround, till the new systemd version finds its way to the OSs, right?
(Which can take quite a time in some cases - as for RHEL7 I have no idea when or if it will be updated (ever) - but as I said, we don't use the aliases there anyway)

Michal Schorm

Good luck to find a workaround for the systemd behavior prior the fix... Units that are not referenced are not pre-loaded, hence the wrong behavior.

Those systemd aliases are provided for compatibility purpose right? That is, one administrator and older backend tools (such as those provided by our own software) can continue relying on mysql service name to act on the SQL service without having to known the vendor (MariaDB or MySQL).

The problem with systemd unit aliases is that those are not really aliases. I had a hard discussion lately with Lennart Poettering regarding the alias definition. From my point of view when you act on an alias, the behavior should remain same as if you act on the unit that define that alias. Unfortunately, that is not currently the case. See the https://github.com/systemd/systemd/issues/7874 issue for futher understanding.

That is why I think that providing those aliases can lead to confusion and unexpected behavior (from end-users point of view) because acting on them is not transparent. Think of the case where you have an unit defining an alias and then, you try to enable the service using the alias instead of the real unit. Here, if the real unit is already enabled, systemd will fails miserably while we could expect a NOOP (command status 0) like that is the case when you try to enable an unit which is already enabled.

That why I did recommend to remove those aliases and force administrators and tool's maintainers to operate on real service name. Sometime, we need go ahead.

Laurent Declercq

We understand each other. Just the "workaround" wasn't the correct term. A "fix till that time" would be appropriate.

The removal of those aliases - either for good or till systemd fix reach OSs - sound's like a reasonable solution to me.

Other notes while I think of them:

Distro's installing links in /etc/systemd/system/ seems the wrong place to do it. Seems like this was meant to be user configurable space only. If these weren't created by systemd this would seems like a good way to confuse aliases too.

When I added the aliases in the first systemd definitions for mariadb I was just loosely following what was possible/suggested/elsewhere. I don't have a great overwhelming story apart from a vague concept that other services depending on the alias rather than an implementation. Interesting read of the meaning of Aliases in the github issue. Thanks for getting to a point of clarity.

For users to add a dependency on mariadb they can override /etc/systemd/system/YYY.service.d/XXXX.conf and add [Unit]..After=mariadb.service and the rest of the configuration will be based on the YYY.service will come from the system definition. They could add a mariadb alias in a similar way if they wanted and that would be better than editing the init file. Adding a https://mariadb.com/kb/en/library/systemd/ section on this with the lessons learnt from this MDEV would be useful if aliases are discussed in any meaningful way.

might be the same as MDEV-15526

This affects an old version of the server (10.1). If this problem persists with an up-to-date version, please open a new ticket.