Bug 1014311 - RFE: allow systemctl enable work on symlinked units
RFE: allow systemctl enable work on symlinked units
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
:
: 1019270 1089700 1096899 1184960 (view as bug list)
Depends On:
Blocks: 981116 1013003 1077757 1427383
  Show dependency treegraph
 
Reported: 2013-10-01 13:19 EDT by Dan Kenigsberg
Modified: 2017-02-28 03:44 EST (History)
33 users (show)

See Also:
Fixed In Version: systemd-228-1.fc24
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1427383 (view as bug list)
Environment:
Last Closed: 2016-03-21 03:28:58 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
mysql compatibility service file (157 bytes, text/plain)
2014-01-13 16:06 EST, Ben Nemec
no flags Details

  None (edit)
Description Dan Kenigsberg 2013-10-01 13:19:37 EDT
Description of problem:
`systemctl enable mysqld.service` fails with 
Failed to issue method call: No such file or directory
($?=1)

Version-Release number of selected component (if applicable):
mariadb-5.5.32-12.fc20.x86_64

How reproducible:
100%

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:
The command should be re-directed to `systemctl enable mariadb.service`, much like `systemctl disable mysqld.service` is.

Additional info:
This is required too keep mariadb a drop-in replacement to mysql.
Comment 1 Honza Horak 2013-10-02 08:40:39 EDT
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.
Comment 2 Honza Horak 2013-10-02 10:48:12 EDT
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.
Comment 3 Lennart Poettering 2013-10-03 08:08:50 EDT
is mariadb.service/mysql.service a symlink in /usr/lib or something like that?
Comment 4 Honza Horak 2013-10-03 08:26:35 EDT
(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.
Comment 5 Lennart Poettering 2013-10-03 12:46:10 EDT
"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.
Comment 6 Honza Horak 2013-10-04 02:20:38 EDT
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
Comment 7 Michal Schmidt 2013-10-15 09:07:57 EDT
*** Bug 1019270 has been marked as a duplicate of this bug. ***
Comment 8 Victor Costan 2013-12-02 19:15:57 EST
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!
Comment 9 Jeff Bailey 2013-12-18 22:12:51 EST
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).
Comment 10 Honza Horak 2013-12-19 04:00:46 EST
(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.
Comment 11 Ben Nemec 2014-01-13 16:04:22 EST
(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.
Comment 12 Ben Nemec 2014-01-13 16:06:22 EST
Created attachment 849629 [details]
mysql compatibility service file
Comment 13 Honza Horak 2014-01-16 06:33:50 EST
(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).
Comment 14 Ben Nemec 2014-01-16 16:32:08 EST
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.
Comment 15 Honza Horak 2014-01-17 02:45:32 EST
(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
Comment 16 Jonathan Ryshpan 2014-02-09 21:24:49 EST
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.
Comment 17 g. artim 2014-02-17 12:43:58 EST
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.
Comment 18 g. artim 2014-02-17 13:33:04 EST
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
Comment 19 Honza Horak 2014-02-19 06:39:34 EST
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=
Comment 20 Jóhann B. Guðmundsson 2014-02-19 08:38:43 EST
(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.
Comment 21 Honza Horak 2014-02-19 08:56:45 EST
(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.
Comment 22 asif2k 2014-03-09 12:38:22 EDT
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?
Comment 23 Honza Horak 2014-04-22 11:58:01 EDT
(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'
Comment 24 Honza Horak 2014-04-22 11:58:04 EDT
*** Bug 1089700 has been marked as a duplicate of this bug. ***
Comment 25 Honza Horak 2014-04-22 11:58:51 EDT
(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'
Comment 26 Martin Pitt 2014-11-25 08:15:26 EST
(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?
Comment 27 Martin Pitt 2014-11-25 08:20:58 EST
(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?
Comment 28 Jan "Yenya" Kasprzak 2014-12-16 05:06:22 EST
Please consider allowing symlinked unit files. My use case is described here: 

https://bugzilla.redhat.com/show_bug.cgi?id=955379#c23
Comment 29 Jóhann B. Guðmundsson 2014-12-16 05:32:14 EST
Your units should reside in /etc/systemd/system
Comment 30 Jan "Yenya" Kasprzak 2014-12-16 05:38:45 EST
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).
Comment 31 Fedora End Of Life 2015-01-09 15:04:03 EST
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.
Comment 32 Jan "Yenya" Kasprzak 2015-01-09 15:08:46 EST
Still present in F21, updating.
Comment 33 Zbigniew Jędrzejewski-Szmek 2015-01-31 15:05:13 EST
*** Bug 1184960 has been marked as a duplicate of this bug. ***
Comment 34 Jan Synacek 2015-10-22 08:01:49 EDT
The patch for this RFE is currently being worked on upstream:
https://github.com/systemd/systemd/pull/1375
Comment 35 Jan Synacek 2015-10-22 08:04:03 EDT
*** Bug 1096899 has been marked as a duplicate of this bug. ***
Comment 36 Piotr Dobrogost 2016-03-20 12:00:51 EDT
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)
Comment 37 Jan Synacek 2016-03-21 03:28:58 EDT
(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.
Comment 38 Piotr Dobrogost 2016-03-21 04:09:30 EDT
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@MyClient.service
5) systemctl enable openvpn@MyClient.service
Is this mistake and if so then what is the right way to enable custom service like this?
Thank you in advance.

Note You need to log in before you can comment on or make changes to this bug.