Bug 1014311

Hm, strange, it works fine with `systemctl status mysqld.service`, but not with `systemctl enable mysqld.service`. Even if I add Alias=mysqld.service to mariadb.service it doesn't work.

I don't thing we can do much about it in mariadb; it sounds more like a problem in systemd, so re-assigning.

Just FYI, the same issue is also exhibited in F19 build of mariadb package, but the other way round, because the links were different there, which means `systemctl enable/disable mariadb.service` doesn't work, while `systemctl start/stop/status mariadb.service` works.

is mariadb.service/mysql.service a symlink in /usr/lib or something like that?

(In reply to Lennart Poettering from comment #3)
> is mariadb.service/mysql.service a symlink in /usr/lib or something like
> that?

Yes, mysqld.service is a symlink to mariadb.service in F20 and in other way round in F19.

"systemd enable" is a tool for creating/removing symlinks hence it currently refuses operating on instructions that are themselves stored in symlinked files, in order to make sure that what can be disabled can always be reenabled again.

There have been ideas about lifting this limitation somewhat, and allowing reading symlinked files in /usr/lib/systemd/system, but not in /run and /etc, as only in the latter systemctl enable is actually changing things.

So, in a way this is a safety feature, not a bug. That said, we're open to change this behaviour.

I'm actually not much more clever from the comment above, but I thought what could work is the following: I run `systemctl enable mysqld.service`, systemd finds out that mysqld.service is a symlink to mariadb.service and so it won't create links mysqld* in /etc/, but rather executes `systemctl enable mariadb.service` implicitly instead.

It seems to me also that it is not very clearly defined what link in /usr/lib/systemd/system means and how it should behaves. Is it:
A) alternative name for a service?
B) a new service with the same unit file content?

But anyway -- in both these cases 'enable' should work, only the output would be different:
A) the same link would be created for all such services
B) various links would be created for various services

*** Bug 1019270 has been marked as a duplicate of this bug. ***

FWIW, if it's not desirable to make "systemctl enable" smarter, it would be nice if would print out a better error message, so I don't have to Google the error message.

"Failed to issue method call: No such file or directory" made me believe there's no mysqld.service. After I saw it was installed, I assumed the error is due to a configuration error in the mariadb package.

Given the listing below, it would be nice if "systemctl enable" would say mysqld.service is a symlink to mariadb.service, and it doesn't like to operate  on symlinks.

$ ls -l /usr/lib/systemd/system/mysqld.service 
lrwxrwxrwx. 1 root root 15 Nov 27 10:21 /usr/lib/systemd/system/mysqld.service -> mariadb.service

Thank you for reading!

Would the best workaround be to remove the mysqld.service symlink and replace it with a copy of mariadb.service?  It's an ugly manual step but maintains the illusion of mysql being installed which many things depend on (packstack on fc20 in my particular case).

(In reply to Jeff Bailey from comment #9)
> Would the best workaround be to remove the mysqld.service symlink and
> replace it with a copy of mariadb.service?  It's an ugly manual step but
> maintains the illusion of mysql being installed which many things depend on
> (packstack on fc20 in my particular case).

I don't think it is a good idea. Some services could require mysqld, while another mariadb and you couldn't satisfy both at a time.

(In reply to Honza Horak from comment #10)
> (In reply to Jeff Bailey from comment #9)
> > Would the best workaround be to remove the mysqld.service symlink and
> > replace it with a copy of mariadb.service?  It's an ugly manual step but
> > maintains the illusion of mysql being installed which many things depend on
> > (packstack on fc20 in my particular case).
> 
> I don't think it is a good idea. Some services could require mysqld, while
> another mariadb and you couldn't satisfy both at a time.

Okay, how about instead of installing duplicate files, we make mysqld.service enable mariadb.service using the Also parameter?  We can add Also to the mariadb.service file as well to make sure that it's not possible to end up with one enabled without the other.  Enabling/disabling/querying would work correctly as far as I can tell.

Ideally systemd would still support the symlink at some point, but since I'm far more capable of writing unit files than hacking the systemd source to allow this, I would be in favor of something to address the problem until someone with systemd expertise can look into it.

I'll attach a service file that seems to work for me.

Created attachment 849629 [details]
mysql compatibility service file

(In reply to Ben Nemec from comment #12)
> Created attachment 849629 [details]
> mysql compatibility service file

That sounds like a good idea to me, but it needs a bit more. The service you propose would work as a wrapper at a time we enable it, but we should also ensure people can use it at a time they start/restart/stop it. So, this is what we could do:

We'd add to mariadb.service:
[Unit]
BindsTo=mysqld.service
[Install]
Also=mysqld.service

And mysqld.service would then contain:
[Unit]
Description=MySQL compatibility service (just another name for mariadb.service; you should use mariadb.service instead)
BindsTo=mariadb.service

[Service]
Type=oneshot
ExecStart=/bin/true
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
Also=mariadb.service

That works just fine in my testing with commands start/restart/stop/enable/disable, so users can use either mariadb or mysqld name, with no differences. I'll make some more testing and will apply in Fedora 20 if there are no issues. 

Any testing or comments on the approach above are welcome.

Side note: I've tried to extend mariadb.service with /etc/systemd/system/mariadb.service.d/mysqld.conf that containing Also=mysqld.service, but I hit a bug probably (reported as #1054161).

I realized last night that I forgot about the start/stop behavior when I tested my service file, but fortunately your BindsTo change works for me too so that looks good to me.

On a semi-related note: It seems that this mysql compat stuff is missing entirely in the RHEL7 beta mariadb packages.  Is that intentional?

Thanks.

(In reply to Ben Nemec from comment #14)
> I realized last night that I forgot about the start/stop behavior when I
> tested my service file, but fortunately your BindsTo change works for me too
> so that looks good to me.

Great, I'll apply it soon.

> On a semi-related note: It seems that this mysql compat stuff is missing
> entirely in the RHEL7 beta mariadb packages.  Is that intentional?

Yes. The story began when we realized that we can't use mysql names in RHEL-7 to make MariaDB look like MySQL entirely and the line was defined as "for every entity creating downstream (log file name, systemd service file, RPM provides of server package...) mariadb will be used; for other things upstream variant will be used (names of binaries, library, etc.)

We've adopted the same changes in Fedora [1], but to not introduce too big changes ant thus problems we still use compatible names mysqld for service names, and so on. Anyway, the correct name for the unit file is mariadb.service, which is what every-one should use and it should work in both RHEL-7 and Fedora.

[1] https://lists.fedoraproject.org/pipermail/devel/2013-August/188099.html

Fedora-20 as distributed has systemd units that are defined as symlinks, in particular nfs.service:
$ ll /usr/lib/systemd/system/nfs.service
lrwxrwxrwx. 1 root root 18 Feb  1 18:54 /usr/lib/systemd/system/nfs.service -> nfs-server.service

This is a trap for the inexpert, since it causes 
   $ systemctl start nfs.service
to work
while
   $ systemctl enable nfs.service
   Failed to issue method call: No such file or directory
doesn't.  As you see, the error message is not very informative.

something broken now...installed updates yesterday and mysqld.service will not start, checked for services files for mysqld.service or mariadb.service in

/usr/lib/systemd/system/mariadb.service


nada, gone are both services. I reinstalled mariadb:

yum reinstall  mariadb mariadb-libs mariadb-devel mariadb-server

no service in /usr/lib/systemd/system/

whats happening. I cant get my db up....please help!

Note that I did the switch from Mysql to Maria so there where probably links for both mysql and maria. but now seems even a reinstall does not provide the systemd files. g.

fix it with:

cp /etc/my.cnf ~/
yum remove   mariadb mariadb-libs mariadb-devel mariadb-server
yum install  mariadb mariadb-libs mariadb-devel mariadb-server
cp /etc/my.cnf /etc/my.cnf.ORIG
cp ~/my.cnf /etc/
systemctl enable mariadb.service
systemctl start mariadb

Re-reading the whole story again, we should keep in mind what the original idea was -- we needed to have two equal names for one service.

One would say we could use Alias= option [1], but it works only when enabling/disabling services, as documented. Was this behaviour the original aim for Alias or it is simply not finished yet?

Anyway, if we don't want to change behaviour of Alias, could another similar option, that would allow to use alias-behaviour also for start/stop/etc., be introduced? Or is there a design block to do so?

[1] http://www.freedesktop.org/software/systemd/man/systemd.unit.html#Alias=

(In reply to Honza Horak from comment #19)
> Re-reading the whole story again, we should keep in mind what the original
> idea was -- we needed to have two equal names for one service.

No we dont we should not be introducing multiple name hacks for unit files.

(In reply to Jóhann B. Guðmundsson from comment #20)
> (In reply to Honza Horak from comment #19)
> > Re-reading the whole story again, we should keep in mind what the original
> > idea was -- we needed to have two equal names for one service.
> 
> No we dont we should not be introducing multiple name hacks for unit files.

OK, then what is the use case for Alias? I don't see any except for target units, so I'd expect that documented in systemd.unit(5) as well.

When I run the command on my FEDORA 20, MySQL 5.5 server. I run the command,

 "systemctl enable mysqld.service"  I get a error "failed to issue method call: no such file or directory"  

Is this a known issue? It seems this is a BUG. as I am reading here. Is this is problem in the Fedora 20 server.   When I try to run the command so that I can run MySQL/MariaDB at boot.  when it restarts my system. I always have to start the MySQL service manually?  Is there any workaround for this?

(In reply to asif2k from comment #22)
> When I run the command on my FEDORA 20, MySQL 5.5 server. I run the command,
> 
>  "systemctl enable mysqld.service"  I get a error "failed to issue method
> call: no such file or directory"  
> 
> Is this a known issue? It seems this is a BUG. as I am reading here. Is this
> is problem in the Fedora 20 server.   When I try to run the command so that
> I can run MySQL/MariaDB at boot.  when it restarts my system. I always have
> to start the MySQL service manually?  Is there any workaround for this?

`systemd enable` only creates symlinks for appropriate target, so you can create the symlinks by hand:
# ln -s '/usr/lib/systemd/system/mysqld.service' '/etc/systemd/system/multi-user.target.wants/mysqld.service'
# ln -s '/usr/lib/systemd/system/mariadb.service' '/etc/systemd/system/multi-user.target.wants/mariadb.service'

*** Bug 1089700 has been marked as a duplicate of this bug. ***

(In reply to asif2k from comment #22)
> When I run the command on my FEDORA 20, MySQL 5.5 server. I run the command,
> 
>  "systemctl enable mysqld.service"  I get a error "failed to issue method
> call: no such file or directory"  
> 
> Is this a known issue? It seems this is a BUG. as I am reading here. Is this
> is problem in the Fedora 20 server.   When I try to run the command so that
> I can run MySQL/MariaDB at boot.  when it restarts my system. I always have
> to start the MySQL service manually?  Is there any workaround for this?

`systemd enable` only creates symlinks for appropriate target, so you can create the symlinks by hand:
# ln -s '/usr/lib/systemd/system/mysqld.service' '/etc/systemd/system/multi-user.target.wants/mysqld.service'
# ln -s '/usr/lib/systemd/system/mariadb.service' '/etc/systemd/system/multi-user.target.wants/mariadb.service'

(In reply to Lennart Poettering from comment #5)
> There have been ideas about lifting this limitation somewhat, and allowing
> reading symlinked files in /usr/lib/systemd/system, but not in /run and
> /etc, as only in the latter systemctl enable is actually changing things.

I'm afraid I don't understand the justification here -- enable always creates wants/ symlinks in /etc, regardless of whether the unit lives in /usr or /etc, doesn't it?

Making symlinks behave one way for units in /usr and and another way for /etc or /run seems even more confusing to me.  IMHO it should consistently behave regardless of where units are, and either

 a) If this is meant to be a "safety feature", keep the current behaviour and improve the error message to say what's going on, or

 b) Always resolve symlinks and then enable/disable the unit that it's pointing to.

> So, in a way this is a safety feature, not a bug. That said, we're open to
> change this behaviour.

In our case we have this problem with "display-manager.service" (which is a link in /etc/ to e. g. gdm.service). You could have gdm, kdm, and lightdm installed, and exactly one gets enabled at any time. "systemctl disable display-manager" makes sense in this context, and I don't think it's unexpected/surprising if this disables the actual DM that's the default (like gdm.service).

On the other hand, I see how this may be surprising/unexpected if "disable mariadb" disables mysql. Is that what you want to guard against?

(In reply to Martin Pitt from comment #26)
> In our case we have this problem with "display-manager.service" (which is a
> link in /etc/ to e. g. gdm.service). You could have gdm, kdm, and lightdm
> installed, and exactly one gets enabled at any time. "systemctl disable
> display-manager" makes sense in this context, and I don't think it's
> unexpected/surprising if this disables the actual DM that's the default
> (like gdm.service).

Ah, I see where my confusion comes from in this case: in this case, "disable" makes perfect sense, but "enable" of course doesn't -- systemctl can't know which of the installed "real" DMs (which all have Alias=display-manager.service) you actually want to enable. But this is a "multiple choice" use case.

For the mariadb use case here (which isn't "multiple choice", just a single "alias") there is no such ambiguity on a low technical/filesystem level. But it's not at all clear how an admin interprets "systemctl disable mariadb; systemctl enable mysql" -- did you just select between the two DBs and just switched from one to the other? (whereas in reality this was a no-op)

So I think I understand the "safety feature" bit for "enable" at least -- what I don't understand is why the behaviour should be different for units in /usr?

Please consider allowing symlinked unit files. My use case is described here: 

https://bugzilla.redhat.com/show_bug.cgi?id=955379#c23

Your units should reside in /etc/systemd/system

Well, this would not allow to systemctl enable/disable my units. Also, I use the unitname@.service wildcard syntax, and I guess I would also have to handle wildcards myself (correct me if I am wrong).

This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Still present in F21, updating.

*** Bug 1184960 has been marked as a duplicate of this bug. ***

The patch for this RFE is currently being worked on upstream:
https://github.com/systemd/systemd/pull/1375

*** Bug 1096899 has been marked as a duplicate of this bug. ***

https://github.com/systemd/systemd/pull/1375 mentioned here in comment 34 was replaced by
https://github.com/systemd/systemd/pull/1515 which was merged on Nov 12, 2015.

How to find out the first version of systemd which includes commit f1637bd (https://github.com/systemd/systemd/commit/f1637bd3a81fe0468b53d7aa91b44cc0c34410d7) which merges pull 1515?


For those interested in history of this feature here are links to subsequent PRs:

install: follow symlinks when enabling unit files from /usr/ #24
(https://github.com/systemd/systemd/pull/24)

Allow aliasing unit files in /usr #40
(https://github.com/systemd/systemd/pull/40)

Make possible to enable unit file via symlink (v2) #382
(https://github.com/systemd/systemd/pull/382)

Make possible to enable unit file via symlink (v3) #910
(https://github.com/systemd/systemd/pull/910)

Make possible to enable unit file via symlink (v4) #923
(https://github.com/systemd/systemd/pull/923)

Make possible to enable unit file via symlink (v5) #1240
(https://github.com/systemd/systemd/pull/1240)

Make possible to enable unit file via symlink (v6) #1364
(https://github.com/systemd/systemd/pull/1364)

Make possible to enable unit file via symlink (v7) #1375
(https://github.com/systemd/systemd/pull/1375)

install: follow unit file symlinks in /usr, but not /etc when looking for [Install] data and more #1515
(https://github.com/systemd/systemd/pull/1515)

(In reply to Piotr Dobrogost from comment #36)
> How to find out the first version of systemd which includes commit f1637bd
> (https://github.com/systemd/systemd/commit/
> f1637bd3a81fe0468b53d7aa91b44cc0c34410d7) which merges pull 1515?

Merged between v227 and v228.

There's related bug #955379 ("systemctl enable fails for symlinks in /etc/systemd/system"). However, it seems the fix in systemd (PR 1515) does not change situation with regard to symlinks in /etc. Could somebody comment in bug #955379 and write what is the reason symlinks in /etc won't work with `systemctl enable`? Also, please notice that creating symlink in /etc and running `systemctl enable` on it is what steps 4 and 5 at https://fedoraproject.org/wiki/Openvpn#Setting_up_a_Linux_OpenVPN_client show:
4) ln -s /lib/systemd/system/openvpn@.service /etc/systemd/system/openvpn
5) systemctl enable openvpn
Is this mistake and if so then what is the right way to enable custom service like this?
Thank you in advance.