Bug 1029476 - '/usr/sbin/service foo disable|enable' not working latest initscripts
'/usr/sbin/service foo disable|enable' not working latest initscripts
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: initscripts (Show other bugs)
7.0
Unspecified Unspecified
high Severity high
: rc
: ---
Assigned To: Václav Pavlín
Jan Ščotka
: Reopened
Depends On: 1029350
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-12 07:53 EST by Václav Pavlín
Modified: 2016-11-25 07:57 EST (History)
5 users (show)

See Also:
Fixed In Version: initscripts-9.49.10-1.el7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1029350
Environment:
Last Closed: 2014-06-13 05:48:01 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 Václav Pavlín 2013-11-12 07:53:25 EST
+++ This bug was initially created as a clone of Bug #1029350 +++

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.

--- Additional comment from Václav Pavlín on 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.

--- Additional comment from Terje Røsten on 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...

--- Additional comment from Václav Pavlín on 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 1 Terje Røsten 2013-11-12 12:15:58 EST
(re-posting in rhel7 branch)

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 enabled

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 2 Václav Pavlín 2013-11-13 03:47:13 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 3 Terje Røsten 2013-11-13 08:07:59 EST
(re-post)

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 5 Ales Zelinka 2013-11-14 08:09:10 EST
Correct me if I'm wrong but pre-systemd 'service xyz enable' only worked if the initscript implemented the action itself i.e. it wasn't a feature of service.

At least that's how service works on rhel6:
# service postfix enable
Usage: /etc/init.d/postfix {start|stop|restart|reload|abort|flush|check|status|condrestart}

Equivalent functionality for rhel7 is to implement the enable/disable actions via the legacy actions[1]. Or calling chkconfig as usual - it works on rhel7 too.

[1] /usr/libexec/initscripts/legacy-actions/
Comment 6 Terje Røsten 2013-11-14 09:42:05 EST
That's correct.
Comment 8 Ludek Smid 2014-06-13 05:48:01 EDT
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.

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