Bug 752774

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.

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

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

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        loaded inactive dead          Getty on tty1
getty        loaded active   running       Getty on tty2
getty        loaded active   running       Getty on tty3
getty        loaded active   running       Getty on tty4
getty        loaded active   running       Getty on tty5
getty        loaded active   running       Getty on tty6
openvpn 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

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

Dirk, if you have a file in /etc/openvpn called myvpn.conf, then do "systemctl start openvpn".

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 -> /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.

(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 -> /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
Failed to issue method call: No such file or directory

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

Any thoughts? Am I missing something, perhaps an selinux or permissions issue?

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.

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

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

I tried the following:

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

and this also failed.

You enable/disable unit files, not units, hence this fails.

(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?

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

which would be using 

sample@.service

which has

sample.target 

which has sample.target.wants directory

When we run systemctl enable sample, the unit would be installed/enabled into the sample.target.wants.

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

I have F17 problem.
the symlink openvpn is created manually.

problem:
openvpn does not start on boot
-----------------
systemctl status openvpn
openvpn - 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

openvpn - 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.

Restart was executed from command line as
systemctl restart openvpn

works OK. On boot fails.

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).

(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.

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, 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.

(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, 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.

(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.

(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.

(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?

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

...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.

(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
> 
> ...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.

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

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

Applied upstream:

http://cgit.freedesktop.org/systemd/systemd/commit/?id=29283ea4cf5df20aa0ea9e24e3cb7035bf4c4a04

systemd-190-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/systemd-190-1.fc18

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).

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).

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).

systemd-44-20.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/systemd-44-20.fc17