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" Actual results: Failed to issue method call: Unit name openvpn is not valid. Expected results: ln -s '/lib/systemd/system/openvpn@.service' '/etc/systemd/system/multi-user.target.wants/openvpn'
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