|
Bugzilla – Full Text Bug Listing |
| Summary: | YaST service manager can't enable foo@.service | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Tumbleweed | Reporter: | Christian Boltz <suse-beta> |
| Component: | YaST2 | Assignee: | E-mail List <yast2-maintainers> |
| Status: | RESOLVED FEATURE | QA Contact: | Jiri Srain <jsrain> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | suse-beta |
| Version: | Current | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | openSUSE 13.2 | ||
| Whiteboard: | |||
| Found By: | Beta-Customer | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
Please provide YaST logs, see http://en.opensuse.org/openSUSE:Bugreport_YaST. This is a non-trivial feature request. Please open a entry in openFATE, see: https://features.opensuse.org/ Displaying an input box if the service name ends with "@" is a "non-trivial feature request"? Seriously?
Since I had written a more verbose explanation before you posted your last comment, let me post it nevertheless - maybe someone can learn something from it ;-)
To make the problem clear: openvpn@ is a so-called "Instantiated Services"), which you can't use directly (but YaST tries to):
# systemctl enable openvpn@.service
Failed to execute operation: Unit name openvpn@.service is not valid.
It's not surprising that systemctl errors out - you _have to_ specify an instance name after the "@". This name will typically be used to determinate the config file name (look for %i in the service file).
This means you have to use something like (note the added "myserver" after the "@"):
# systemctl enable openvpn@myserver.service
It's also possible to have more openvpn instances in parallel, like
# systemctl enable openvpn@myserver.service
# systemctl enable openvpn@cheapvpnprovider.service
# systemctl enable openvpn@geeko.service
(all those commands succeed.)
This all means:
*** If the user wants to start or enable "openvpn@", YaST will need to display
*** an input box where users can enter "myserver" or whatever config name they
*** want to use.
In theory this also applies to stop and disable, however this will never happen in practise because "openvpn@" can never be running or enabled - only something like "openvpn@myserver" can. (On the positive side, YaST will display "openvpn@myserver" in the service list as soon as it's running or enabled, so users can disable or stop it.)
FIY: In the service file, it looks like this:
# systemctl cat openvpn@.service
[...]
ExecStart=/usr/sbin/openvpn --daemon --suppress-timestamps
--writepid /run/openvpn/%i.pid --cd /etc/openvpn/
--config %i.conf
%i gets replaced by "myserver" for openvpn@myserver.service or by "geeko" for openvpn@geeko.service.
If you are interested on the systemd documentation about Instantiated Services, see http://0pointer.de/blog/projects/instances.html
That all said - I opened https://features.opensuse.org/320260
|
YaST service manager can't enable foo@.service (service files with parameters, for example openvpn@.service If I select "openvpn@", click "Start/Stop" to start it and then "OK" to actually start it, I get an error message (translated back from german) Writing the configuration failed: openvpn@ can't be enabled. Failed to get properties: Unit name openvpn@.service is not valid. Would you like to continue editing? [Continue] [Cancel] Expected behaviour: When someone tries to enable a foo@ service, ask for the parameter to use (= display an input field) and then enable foo@<userinput>.service. (not attaching any logs because this is very obvious and easy to reproduce)