Description of problem: /usr/sbin/service foo disable and /usr/sbin/service foo enable worked in fc18 and fc19, now in fc20 this does not work and there are no warning to the user. From FC19: # service sshd disable Redirecting to /bin/systemctl disable sshd.service rm '/etc/systemd/system/multi-user.target.wants/sshd.service' #service sshd status|grep Loaded Redirecting to /bin/systemctl status sshd.service Loaded: loaded (/usr/lib/systemd/system/sshd.service; disabled) # service sshd enable Redirecting to /bin/systemctl enable sshd.service ln -s '/usr/lib/systemd/system/sshd.service' '/etc/systemd/system/multi-user.target.wants/sshd.service' # service sshd status|grep Loaded Redirecting to /bin/systemctl status sshd.service Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled) On FC20, nothing happens when doing service sshd disable service sshd enable not even a warning it don't work. Please restore old and trusted behaviour.
Hi, enable/disable actions in service commands should have never worked in first place. Before systemd you had to use chkconfig to enable/disable the service. We now fixed this behaviour so service command works only with LSB specified actions again so that we can provide correct return code for unknown actions. Please use systemctl or chkconfig for enabling/disabling instead.
At least a warning and a advice how to use systemctl should be added. You can't just remove things like this without deprecate warning. It might be a bug in the first place, however now it's too late. BTW: is this related to: - service: filter actions that are not supported by systemctl in service (#947823) in changelog? I get: You are not authorized to access bug #947823. Seems weird...
Ok, you are right. Mentioning systemctl if the action is not provided by service command would be nice. Patch committed to git -> https://git.fedorahosted.org/cgit/initscripts.git/commit/?id=20103e709fcd6e2a9c21f2c64948736cd81cff9c
Also let me explain why I like service fooserverd disable|enable: Workflow is like this: 1) yum -y install foo-server 2) service fooserverd start 3) service fooserverd status # everything seems good, ready to enable 4) service fooserverd enable 5) service fooserverd status # double check You see on all lines 2-4) the only thing changing is the last argument, arrow up (in history), then delete some chars and then new command, this goes very fast and easy. Using: systemctl start|enable|status fooserverd you have to move over the last word argument (foodserverd) several times, this is slow and error prune. Power to the user/admin is more important than some LSB thingie, agree?
Terje, I got your point, but on the other hand, systemctl provides much more than service command and we would like to encourage users to switch from service to systemctl. If you look back, you had to use chkconfig to enable/disable services and service to start/stop/restart them...Now you have one command that does all of that and much more.
If systemd was user friendly in the first place this would not be a problem. Why create a new command which is 9 letters long? And with no fast tab completion possible and has arguments in wrong order to top it? Think if 'ls' command was renamed to listmyfiles and you had to have options after arguments, like this: $ listmyfiles /etc -lrtc Why can't the guys making this stuff care a bit about the users? Forcing sysadmins to use awkward systemctl command seems strange at best. Ideal would be to introduce a short command, e.g. srv with correct order of arguments and a small subset of needed commands and a nice manual page to follow. $ srv fooserverd stop|start|restart|status|enable|disable Can't be that hard to implement?
So shortly - 1) tab completion works and is really good in my opinion 2) arguments are in correct order - you ask systemctl to start/stop a service - systemct start foo.service 3) if you really need this command to be shorter, just set an alias - sc, maybe? 4) Have you seen man systemctl? I think it is very nice. I can assure you neither the name of systemctl, nor arguments order will change, so I will consider this bug fixed.
1) tab completion don't work nicely with a name such as systemctl, this is not nice, it's useless: $ sys<tab> sysctl systemd-cgls syslog-ng systemd-cgtop syslog-ng-ctl systemd-coredumpctl system-config-authentication systemd-delta system-config-date systemd-detect-virt system-config-keyboard systemd-inhibit system-config-language systemd-loginctl system-config-printer systemd-machine-id-setup system-config-printer-applet systemd-notify system-config-services systemd-nspawn system-config-users systemd-stdio-bridge systemctl systemd-sysv-convert systemd systemd-tmpfiles systemd-analyze systemd-tty-ask-password-agent systemd-ask-password systemsettings systemd-cat sys-unconfig 2) put the most frequent argument to change last, systemctl don't follow this idom. 3) I was hoping creator of tool or distro would provide this. 4) It's huge, 6 full screens (for me) to find enable, it has not priority among very common commands, strange options and obscure commands. Once again, author don't seems to think about the common user. Why are you are able to assure nothing will improve?
1) use alias 2) subject verb object 3) I have an alias git co -> git checkout, should I create a bug for git? 4) Manpage should provide complete information about the tool, if you want shorter help, try --help There is a logic behind the current situation. For example why is systemctl called systemctl system -> systemd -> systemctl journal -> journald -> journalctl machine -> machined -> machinectl Also with the order with systemctl systemctl (what I am calling) start (what I want to do) foo.service (parameter) You are right that these are not completely comfortable to type, but they are LOGICAL and that's what makes them for me user-friendly. And if you are experienced user and you are upset with something, just customize it. > Why are you are able to assure nothing will improve? We are not going to change and can't change the interface to systemctl as it is used for some time now.
Terje sums up exactly why people still use "service" instead of "systemctl".
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. 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 20 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.
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. 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 23 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.
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle. Changing version to '26'.
If 'systemctl enable/disable' does not work as expected, please open a new bug against the systemd package. The way that /sbin/service works is not going to change.