Bug 752774 - Units instantiated from templates cannot be enabled/disabled
Units instantiated from templates cannot be enabled/disabled
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
16
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Michal Sekletar
Fedora Extras Quality Assurance
:
: 746472 754863 789553 806488 821002 838340 (view as bug list)
Depends On:
Blocks: systemd-RFE
  Show dependency treegraph
 
Reported: 2011-11-10 07:16 EST by Tom Hughes
Modified: 2012-10-12 12:45 EDT (History)
30 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-10-07 18:49:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tom Hughes 2011-11-10 07:16:34 EST
Description of problem:

A unit which is instantiated from a template cannot be enabled/disabled with systemctl.

Version-Release number of selected component (if applicable):

systemd-36-3.fc16

How reproducible:

Every time.

Steps to Reproduce:
1. Take a service that uses templates, for example openvpn.
2. Run "systemctl enable openvpn@foo.service"
  
Actual results:

Failed to issue method call: Unit name openvpn@foo.service is not valid.

Expected results:

ln -s '/lib/systemd/system/openvpn@.service' '/etc/systemd/system/multi-user.target.wants/openvpn@foo.service'
Comment 1 Michal Schmidt 2011-11-10 11:30:45 EST
Yeah, I thought about this very issue just yesterday. Since WantedBy=... in the [Install] section does not make sense for the template itself, we should consider it as a description for how to enable the instances of the template.
The template unit may still have the Alias=... option for itself.
Comment 2 Michal Schmidt 2011-11-18 11:27:48 EST
*** Bug 754863 has been marked as a duplicate of this bug. ***
Comment 3 Steven Ellis 2012-01-02 05:41:55 EST
*** Bug 746472 has been marked as a duplicate of this bug. ***
Comment 4 Steven Ellis 2012-01-02 05:45:41 EST
So I'm going to assume this will also affect vncserver

systemctl --all | grep \@
fsck@dev...341e9d.service loaded inactive dead          File System Check on /dev/disk/by-uuid/b7d80a1f-4b1a-4e67-8aab-e844ad341e9d
getty@tty1.service        loaded inactive dead          Getty on tty1
getty@tty2.service        loaded active   running       Getty on tty2
getty@tty3.service        loaded active   running       Getty on tty3
getty@tty4.service        loaded active   running       Getty on tty4
getty@tty5.service        loaded active   running       Getty on tty5
getty@tty6.service        loaded active   running       Getty on tty6
openvpn@mypersonal.service loaded active   running       OpenVPN Robust And Highly Flexible Tunneling Application On mypersonal

ls /lib/systemd/system/*.service | grep \@
/lib/systemd/system/autovt@.service
/lib/systemd/system/fsck@.service
/lib/systemd/system/getty@.service
/lib/systemd/system/openvpn@.service
/lib/systemd/system/serial-getty@.service
/lib/systemd/system/user@.service
/lib/systemd/system/vncserver@.service
Comment 5 Matt Kinni 2012-02-10 01:22:45 EST
Is there any way to temporarily fix this? I can't figure out how to start the openvpn service at all:
systemctl start openvpn@.service
Failed to issue method call: Unit name openvpn@.service is not valid.

I tried renaming it to not have the @ symbol but it still doesn't work
Comment 6 Samuel Sieb 2012-02-10 01:32:04 EST
Dirk, if you have a file in /etc/openvpn called myvpn.conf, then do "systemctl start openvpn@myvpn.service".
Comment 7 brian.broussard 2012-02-10 08:59:29 EST
Dirk, if you want it to auto start place an entry in 

/etc/systemd/system/multi-user.target.wants  

it will look like this 

openvpn@myvpn.service -> /lib/systemd/system/openvpn@.service

so to add for config file /etc/openvpn/myvpn.conf

ln -s /lib/systemd/system/openvpn\@.service /etc/systemd/system/multi-user.target.wants/openvpn\@myvpn.service

thus in traditional methods you would have a server.conf file or a client.conf file in which the service would pick up;  you must pass the info so 

 ln -s /lib/systemd/system/openvpn\@.service /etc/systemd/system/multi-user.target.wants/openvpn\@server.service
or 
ln -s /lib/systemd/system/openvpn\@.service /etc/systemd/system/multi-user.target.wants/openvpn\@client.service

hope that helps.
Comment 8 bob mckay 2012-02-13 02:29:30 EST
(In reply to comment #7)
I tried following this, and appear to have successfully created the symlink:

[root@sc multi-user.target.wants]# ls -Z /etc/systemd/system/multi-user.target.wants | grep openvpn
lrwxrwxrwx. root root system_u:object_r:etc_t:s0       openvpn@sc.service -> /lib/systemd/system/openvpn@.service

[root@sc system]# ls -Z /lib/systemd/system | grep openvpn
-rwxr-xr-x. root root system_u:object_r:systemd_unit_file_t:s0 openvpn@.service

BUT
[root@sc system]# systemctl enable openvpn@sc.service
Failed to issue method call: No such file or directory

However the service is working:
[root@sc system]# systemctl restart openvpn@sc.service
[root@sc system]# 
(and the openvpn connection is working as well). 

Any thoughts? Am I missing something, perhaps an selinux or permissions issue?
Comment 9 Samuel Sieb 2012-02-13 02:35:39 EST
That ln command you ran is the same as systemctl enable.  To disable it, you need to remove that link.  For start/stop/restart, use the command you have there.
Comment 10 Michal Schmidt 2012-02-13 05:13:44 EST
*** Bug 789553 has been marked as a duplicate of this bug. ***
Comment 11 Michal Schmidt 2012-03-23 21:30:08 EDT
*** Bug 806488 has been marked as a duplicate of this bug. ***
Comment 12 Philip Prindeville 2012-03-26 14:03:26 EDT
I tried the following:

% cd /lib/systemd/system
% ln -s clamd@.service clamd@mimedefang.service
% systemctl enable clamd@mimedefang.service

and this also failed.
Comment 13 Lennart Poettering 2012-03-26 14:54:27 EDT
You enable/disable unit files, not units, hence this fails.
Comment 14 Philip Prindeville 2012-04-14 20:20:04 EDT
(In reply to comment #13)
> You enable/disable unit files, not units, hence this fails.

It seems to be a frequent enough misunderstanding amongst users that perhaps this might be changed to be more intuitive?
Comment 15 Jóhann B. Guðmundsson 2012-04-14 21:19:38 EDT
I think the problem to solve here is fixing the lack of template instances being able to be enabled.

The only scalable logical conclusion in larger scheme of things that I can reach to solve this is that we dont try to introduce/support some kind of [Install] section into templates but instead start requiring targets to accommodate each template.

To break what I'm getting at down..

We would have 

sample@sample.service

which would be using 

sample@.service

which has

sample.target 

which has sample.target.wants directory

When we run systemctl enable sample@sample.service, the unit would be installed/enabled into the sample.target.wants.
Comment 16 Michal Schmidt 2012-05-11 11:10:49 EDT
*** Bug 821002 has been marked as a duplicate of this bug. ***
Comment 17 Need Real Name 2012-06-16 11:43:21 EDT
I have F17 problem.
the symlink openvpn@server.service is created manually.

problem:
openvpn does not start on boot
-----------------
systemctl status openvpn@server.service
openvpn@server.service - OpenVPN Robust And Highly Flexible Tunneling Application On server
          Loaded: loaded (/lib/systemd/system/openvpn@.service; enabled)
          Active: failed (Result: exit-code) since Sat, 16 Jun 2012 07:20:46 -0400; 4h 11min ago
         Process: 943 ExecStart=/usr/sbin/openvpn --daemon --writepid /var/run/openvpn/%i.pid --cd /etc/openvpn/ --config %i.conf (code=exited, status=1/FAILURE)
          CGroup: name=systemd:/system/openvpn@.service/server

Jun 16 07:20:46 mcpmp openvpn[943]: pkcs11_protected_authentication = DISABLED
-------------

but manual restart works OK
systemctl status openvpn@server.service

openvpn@server.service - OpenVPN Robust And Highly Flexible Tunneling Application On server
          Loaded: loaded (/lib/systemd/system/openvpn@.service; enabled)
          Active: active (running) since Sat, 16 Jun 2012 11:32:58 -0400; 20s ago
         Process: 1142 ExecStart=/usr/sbin/openvpn --daemon --writepid /var/run/openvpn/%i.pid --cd /etc/openvpn/ --config %i.conf (code=exited, status=0/SUCCESS)
        Main PID: 1154 (openvpn)
          CGroup: name=systemd:/system/openvpn@.service/server
                  └ 1154 /usr/sbin/openvpn --daemon --writepid /var/run/ope...

Jun 16 11:33:03 mcpmp openvpn[1154]: 1.1.1.1:13253 Data Channel Encryp...on
--------
can you provide SysV scripts.
I think this systemd garbage is unfixable.
Comment 18 Need Real Name 2012-06-16 11:49:35 EDT
Restart was executed from command line as
systemctl restart openvpn@server.service

works OK. On boot fails.
Comment 19 Need Real Name 2012-06-17 03:20:10 EDT
The reason of mentioned openvpn failure is not #752774 related,
but is a different issue:
if server.conf has a line 
local 192.168.1.11 
(bind & listen on 192.168.1.11:1194 )
Openvpn fails starting on boot with a message "cannot bind"
probably some strange interaction with network manager.
Same bind on 192.168.1.11:1194 works perfectly OK after boot.

A workaround was to remove "local 192.168.1.11" 
so openvpn would listen on 0/0:1194
This works fine on boot.

systemd fails to resolve the issue it was designed for (dependencies).
I think this is the overengeeneving garbage from the 
authors of another garbage (pulseaudio).
Comment 20 Tom Hughes 2012-06-17 03:29:18 EDT
(In reply to comment #19)
> The reason of mentioned openvpn failure is not #752774 related,
> but is a different issue:
> if server.conf has a line 
> local 192.168.1.11 
> (bind & listen on 192.168.1.11:1194 )
> Openvpn fails starting on boot with a message "cannot bind"
> probably some strange interaction with network manager.
> Same bind on 192.168.1.11:1194 works perfectly OK after boot.
> 
> A workaround was to remove "local 192.168.1.11" 
> so openvpn would listen on 0/0:1194
> This works fine on boot.

That is, as you say, an unrelated issue.

The best solution would be for openvpn to use IP_FREEBIND so that it can bind to the address evenm if it doesn't exist yet.

A workaround is to enable NetworkManager-wait-online.service so that things which depend on network.target (like openvpn) only start once NetworkManager has finished bringing the network up.
Comment 21 Michal Sekletar 2012-06-19 03:43:38 EDT
I would like to work on this, but I don't agree with Johann. I don't think that creation of more targets is correct approach here. Behavior I propose could be as follows. #systemctl enable unit@instance.service, creates only symlink in .wants directory of particular target, so basically systemd will do exactly the same thing as Tom requested in the Description of this bug. If someone has particular reason in mind, why this is not the right solution to this problem, it would be nice to hear it. Thank you.
Comment 22 Jóhann B. Guðmundsson 2012-06-19 07:59:49 EDT
(In reply to comment #21)
> I would like to work on this, but I don't agree with Johann. I don't think
> that creation of more targets is correct approach here. Behavior I propose
> could be as follows. #systemctl enable unit@instance.service, creates only
> symlink in .wants directory of particular target, so basically systemd will
> do exactly the same thing as Tom requested in the Description of this bug.
> If someone has particular reason in mind, why this is not the right solution
> to this problem, it would be nice to hear it. Thank you.

The reason I suggested targets is administration and scalability. 

We have already had a complaint on a report from an administrator that found it difficult to manage 50 instances of ftp daemon which he had to do for the ISP company he worked for.

When you use template units you will be managing alot of units for the same service/daemon so the solution in mind needs to be scalable and it's my experience it is best to create a target with it's own target.wants directory for a relevant service/daemon unit once you reach ca 5+ units in total regardless if they are template or "cloned" standalone units and have those units "BindTo=" that target which gives the administrator the ability to start/restart/reload/stop all the instances of that service/daemon in a single command, which he might have to do after update/upgrade of the relevant component for the daemon/service since our rpm update/upgrade process only restarts the single unit for that daemon/service and for other general administrative tasks.
Comment 23 Michal Sekletar 2012-06-20 04:40:25 EDT
(In reply to comment #22)
> The reason I suggested targets is administration and scalability. 

My initial impression that creating an additional targets will be just too much, is gone now, since administrators are often dealing with big number of instances and they want to have an option to enable/disable them in a comfortable way. So in the end I have to say that it makes perfect sense, although not in every case, to create the additional target when enabling/disabling instantiated service.

> We have already had a complaint on a report from an administrator that found 
> it difficult to manage 50 instances of ftp daemon which he had to do for the I
> ISP company he worked for.

Yes I saw the bug #719343, and I admit that current situation is unpleasant. 

To be honest I still don't know exactly what will be the correct approach here. The another thing is that systemd already supports [Install]Alias=, and I think this is kind of a hack, since template service file were not meant to be enabled, so this configuration option, doesn't make much sense. It is just to hack to bypass current behavior, e.g. getty@.service.

Maybe it will worth to think about new option for instantiated service, where it will be possible to redefine some default behavior, in case when an expected use case is to run a large number of daemon instances. When first instance is enabled systemd will create desired target and all subsequent calls to enable another instance will be place it under newly created target.

Another issue I can think of is a situation, when admin has many configuration files and he is about to run many instances of some daemon. In such a case, even with new option to create target for the service in question, he still have to call systemctl enable many times. It will be nice to have a way how to automatize this, so we don't force admins to do this manual work or write more helper scripts.
Comment 24 Michal Sekletar 2012-06-20 04:42:44 EDT
(In reply to comment #23)
> Yes I saw the bug #719343, and I admit that current situation is unpleasant. 

It was bug #719434, sorry for typo.
Comment 25 Jóhann B. Guðmundsson 2012-06-20 06:12:25 EDT
(In reply to comment #23)
> (In reply to comment #22)
> To be honest I still don't know exactly what will be the correct approach
> here. The another thing is that systemd already supports [Install]Alias=,
> and I think this is kind of a hack, since template service file were not
> meant to be enabled, so this configuration option, doesn't make much sense.
> It is just to hack to bypass current behavior, e.g. getty@.service.

I dont think we should add an specific [Install] section to templates we just leave the templates without it as is and do as you propose here below with the addition to BindTo= by default the template units that bears the same name as the preceding suffix to @ as in example@.service would BindTo=example.target if it existed so that administrators can control starting/reloading/restarting/stopping all template units instances with one command.

> 
> Maybe it will worth to think about new option for instantiated service,
> where it will be possible to redefine some default behavior, in case when an
> expected use case is to run a large number of daemon instances. When first
> instance is enabled systemd will create desired target and all subsequent
> calls to enable another instance will be place it under newly created target.

Agreed administrators can then control there in the newly created target which boot ( or any other ) target that target gets [Install] to.

But by default the newly create target should be link to the multi-user.target

> Another issue I can think of is a situation, when admin has many
> configuration files and he is about to run many instances of some daemon. In
> such a case, even with new option to create target for the service in
> question, he still have to call systemctl enable many times. It will be nice
> to have a way how to automatize this, so we don't force admins to do this
> manual work or write more helper scripts.

Agreed so here we need something like "WorkingConf="

Where administrators defines configuration files themselves or the ending of the configuration file(s) to use with an wildcard as in.. 

WorkingConf=example.conf example1.conf example2.conf

or

WorkingConf=*.conf

Then we just (re)use WorkingDirectory= where users set the path to directory which contains the configuration files as in 

WorkingDirectory=/etc/example

And I would put the above as an addition to targets not templates so users enables the newly created target and then has to start the newly created target and when it is started it will automatically parse and generate template units based on what is in the newly introduced option and when the newly created target is shutdown ( either manually or via the shutdown process ) it re-parses the configuration directory defined and automatically removes the template units that no longer have configuration files associated with them.

Does the above make sense to you?
Comment 26 Scott Shambarger 2012-06-26 16:04:22 EDT
Back to the original bug (really an enhancement request?)... it would be quite intuitive to be able to enable a service instance based on a template.  Linking the file directly is nice, but doesn't allow for "correct" behavior without quite a bit of special casing, such as handling /etc/systemd vs /lib/systemd unit files, or --system vs --user modes, not to mention remote enabling with systemctl -H.

# systemctl enable openvpn@server.service

...should really just work. :)

Having a programmatic way to enable/disable a service instance that handles all those special cases seems like a valuable addition... and solves the confusion people have with [Install]Alias= entries being able to enable an instance on install.
Comment 27 Philip Prindeville 2012-06-26 17:27:37 EDT
(In reply to comment #26)
> Back to the original bug (really an enhancement request?)... it would be
> quite intuitive to be able to enable a service instance based on a template.
> Linking the file directly is nice, but doesn't allow for "correct" behavior
> without quite a bit of special casing, such as handling /etc/systemd vs
> /lib/systemd unit files, or --system vs --user modes, not to mention remote
> enabling with systemctl -H.
> 
> # systemctl enable openvpn@server.service
> 
> ...should really just work. :)
> 
> Having a programmatic way to enable/disable a service instance that handles
> all those special cases seems like a valuable addition... and solves the
> confusion people have with [Install]Alias= entries being able to enable an
> instance on install.

Seconded. If you run large numbers of instances of mimedefang, clamav, sendmail, postfix, cyrus, etc. then templating in this way becomes indispensable.
Comment 28 Michal Sekletar 2012-07-03 06:12:56 EDT
I have sent two patches[1][2] addressing this issue to upstream mailing list. Feedback and suggestions to code improvements are greatly appreciated. Thank you.

[1] http://lists.freedesktop.org/archives/systemd-devel/2012-July/005774.html
[2] http://lists.freedesktop.org/archives/systemd-devel/2012-July/005775.html
Comment 29 Michal Sekletar 2012-07-09 03:52:01 EDT
*** Bug 838340 has been marked as a duplicate of this bug. ***
Comment 31 Fedora Update System 2012-09-20 15:56:55 EDT
systemd-190-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/systemd-190-1.fc18
Comment 32 Fedora Update System 2012-09-22 02:38:03 EDT
Package systemd-191-2.fc18, rtkit-0.11-3.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-191-2.fc18 rtkit-0.11-3.fc18'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-14581/rtkit-0.11-3.fc18,systemd-191-2.fc18
then log in and leave karma (feedback).
Comment 33 Fedora Update System 2012-09-27 20:18:35 EDT
Package glibc-2.16-17.fc18, systemd-192-1.fc18, selinux-policy-3.11.1-23.fc18, rtkit-0.11-3.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing glibc-2.16-17.fc18 systemd-192-1.fc18 selinux-policy-3.11.1-23.fc18 rtkit-0.11-3.fc18'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-14581/selinux-policy-3.11.1-23.fc18,rtkit-0.11-3.fc18,systemd-192-1.fc18,glibc-2.16-17.fc18
then log in and leave karma (feedback).
Comment 34 Fedora Update System 2012-10-01 16:11:27 EDT
Package glibc-2.16-17.fc18, rtkit-0.11-3.fc18, systemd-193-1.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing glibc-2.16-17.fc18 rtkit-0.11-3.fc18 systemd-193-1.fc18'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-14581/rtkit-0.11-3.fc18,systemd-193-1.fc18,glibc-2.16-17.fc18
then log in and leave karma (feedback).
Comment 35 Fedora Update System 2012-10-12 12:45:51 EDT
systemd-44-20.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/systemd-44-20.fc17

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