Bug 1029350 - '/usr/sbin/service foo disable|enable' not working in FC20+
'/usr/sbin/service foo disable|enable' not working in FC20+
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: initscripts (Show other bugs)
26
Unspecified Unspecified
unspecified Severity high
: ---
: ---
Assigned To: Lukáš Nykrýn
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: 1029476
  Show dependency treegraph
 
Reported: 2013-11-12 03:51 EST by Terje Røsten
Modified: 2017-08-02 09:21 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1029476 (view as bug list)
Environment:
Last Closed: 2017-08-02 09:21:11 EDT
Type: Bug
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 Terje Røsten 2013-11-12 03:51:27 EST
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.
Comment 1 Václav Pavlín 2013-11-12 04:25:52 EST
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.
Comment 2 Terje Røsten 2013-11-12 05:53:36 EST
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...
Comment 3 Václav Pavlín 2013-11-12 07:49:26 EST
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
Comment 4 Terje Røsten 2013-11-12 12:13:28 EST
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?
Comment 5 Václav Pavlín 2013-11-13 03:50:49 EST
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.
Comment 6 Terje Røsten 2013-11-13 06:13:45 EST
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?
Comment 7 Václav Pavlín 2013-11-13 06:48:25 EST
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.
Comment 8 Terje Røsten 2013-11-13 08:26:27 EST
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?
Comment 9 Lukáš Nykrýn 2013-11-13 09:01:47 EST
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.
Comment 10 Paul Wouters 2014-02-10 09:42:08 EST
Terje sums up exactly why people still use "service" instead of "systemctl".
Comment 11 Fedora End Of Life 2015-05-29 05:44:15 EDT
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.
Comment 12 Jan Kurik 2015-07-15 10:44:21 EDT
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
Comment 13 Fedora End Of Life 2016-11-24 06:04:26 EST
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.
Comment 14 Fedora End Of Life 2017-02-28 04:35:55 EST
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.
Comment 15 Zbigniew Jędrzejewski-Szmek 2017-08-02 09:21:11 EDT
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.

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