RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1029476 - '/usr/sbin/service foo disable|enable' not working latest initscripts
Summary: '/usr/sbin/service foo disable|enable' not working latest initscripts
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: initscripts
Version: 7.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Václav Pavlín
QA Contact: Jan Ščotka
URL:
Whiteboard:
Depends On: 1029350
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-11-12 12:53 UTC by Václav Pavlín
Modified: 2016-11-25 12:57 UTC (History)
5 users (show)

Fixed In Version: initscripts-9.49.10-1.el7
Doc Type: Bug Fix
Doc Text:
Clone Of: 1029350
Environment:
Last Closed: 2014-06-13 09:48:01 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Václav Pavlín 2013-11-12 12:53:25 UTC
+++ 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 17:15:58 UTC
(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 08:47:13 UTC
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 13:07:59 UTC
(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 13:09:10 UTC
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 14:42:05 UTC
That's correct.

Comment 8 Ludek Smid 2014-06-13 09:48:01 UTC
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.