Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Won't Fix
-
10.1.26
-
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 9.2 (stretch)
Release: 9.2
Codename: stretch
Description
Under Debian Stretch, the MariaDB server comes with the mariadb service unit:
- /lib/systemd/system/mariadb.service
The mysql and mysqld service units are also provided as aliases (alternative names):
- /etc/systemd/system/mysql.service (symlink to /lib/systemd/system/mariadb.service)
- /etc/systemd/system/mysqld.service (symlink to /lib/systemd/system/mariadb.service)
In our environment we have a cron task that is responsible to renew our let's encrypt SSL certificates. That cron task check that the mysql service is running prior doing anything else and exit if the service is not running. We execute the following command to check the service:
systemctl is-active mysql
|
Lately, one of our certificate has not been renewed. After some investigation, we have found that the command above report the mysql service as inactive while it is active. However, the same command on the mariadb service unit report the service as active.
Executing the systemctl status mysql command seem to solve the problem because when re-running the systemctl is-active mysql command just after, the service is reported as active. That is really a weird issue.
Attachments
Activity
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.
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.
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.