Bug 1414544 - systemctl status should report init script enabled status
Summary: systemctl status should report init script enabled status
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: systemd
Version: 7.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Jan Synacek
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-01-18 19:55 UTC by Stephen Wadeley
Modified: 2017-05-09 13:23 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-05-09 13:23:57 UTC
Target Upstream Version:


Attachments (Terms of Use)
patch (3.47 KB, patch)
2017-01-20 13:55 UTC, Jan Synacek
msekleta: review+
Details | Diff

Description Stephen Wadeley 2017-01-18 19:55:06 UTC
Description of problem:

systemctl status command does not report enabled status for sysv init script process.


Version-Release number of selected component (if applicable):

~]# systemctl --version
systemd 219


Steps to Reproduce:

systemctl status jenkins 


Actual results:

 ~]# systemctl status jenkins
● jenkins.service - LSB: Jenkins Continuous Integration Server
   Loaded: loaded (/etc/rc.d/init.d/jenkins)
   Active: active (running) since Tue 2017-01-17 12:29:37 CET; 1h 13min ago
     Docs: man:systemd-sysv-generator(8)
  Process: 1295 ExecStart=/etc/rc.d/init.d/jenkins start (code=exited, status=0/SUCCESS)



Expected results:

 ~]# systemctl status jenkins
● jenkins.service - LSB: Jenkins Continuous Integration Server
   Loaded: loaded (/etc/rc.d/init.d/jenkins); enabled by chkconfig;
   Active: active (running) since Tue 2017-01-17 12:29:37 CET; 1h 13min ago
     Docs: man:systemd-sysv-generator(8)
  Process: 1295 ExecStart=/etc/rc.d/init.d/jenkins start (code=exited, status=0/SUCCESS)



Additional info:

Comment 1 Jan Synacek 2017-01-19 13:15:29 UTC
This would result in an ugly hack... Do we really want this? You can always run "systemctl is-enabled <service>" which already does a good job on the sysv scripts.

Comment 2 Stephen Wadeley 2017-01-19 13:41:05 UTC
(In reply to Jan Synacek from comment #1)
> This would result in an ugly hack... Do we really want this? You can always
> run "systemctl is-enabled <service>" which already does a good job on the
> sysv scripts.

Precisely because the information is available via "systemctl is-enabled <service>" I could not understand why the output from systemctl status is not consistent in this case.

You are suggesting the user learn more commands, and the short comings of each command, to get this information. This seems a strange contrast to the verbose output of the systemctl status command.

Comment 3 Jan Synacek 2017-01-19 14:07:16 UTC
(In reply to Stephen Wadeley from comment #2)
> (In reply to Jan Synacek from comment #1)
> > This would result in an ugly hack... Do we really want this? You can always
> > run "systemctl is-enabled <service>" which already does a good job on the
> > sysv scripts.
> 
> Precisely because the information is available via "systemctl is-enabled
> <service>" I could not understand why the output from systemctl status is
> not consistent in this case.

It's not really available, that's my concern. I'm not sure how this is done in the current RHEL7 version, but in the upstream sources we "fake" this information by forking an external binary that was specifically written for this purpose. We examine its return code and if it's 0, we puts("enabled"). That is, the information is not really available via the internal API.

The patch for your request should be easy, it would just make things even uglier. I would like to hear from the rest of the team before implementing it.

Comment 4 Stephen Wadeley 2017-01-20 09:16:12 UTC
thanks for the explanation

Comment 5 Jan Synacek 2017-01-20 13:55:51 UTC
Created attachment 1242820 [details]
patch

It's ugly, but it works.

Comment 6 Jan Synacek 2017-01-20 13:56:21 UTC
I forgot to add that this patch is against the upstream version, not the RHEL7 version.

Comment 7 Michal Sekletar 2017-02-08 13:33:15 UTC
(In reply to Jan Synacek from comment #6)
> I forgot to add that this patch is against the upstream version, not the
> RHEL7 version.

Patch looks reasonable. I just have couple of nitpicks that I'd like to see addressed before posting upstream. Please create PR on your Github fork where I can properly review the patch. Bugzilla is utterly useless as a code review platform.

Comment 8 Jan Synacek 2017-02-09 13:43:19 UTC
https://github.com/systemd/systemd/pull/5288

Comment 10 Jan Synacek 2017-02-16 09:41:27 UTC
Right now, it doesn't look like upstream accepts such patches.

Comment 13 Jan Synacek 2017-05-09 13:23:57 UTC
I tried to backport my patch from comment 8, but it requires the status of the generated unit files to be "generated", which was added in https://github.com/systemd/systemd/commit/f413930863ab3b98cb7bf9e761081b4e88a5d7d9 and that requires generator dir logic rework implemented in https://github.com/systemd/systemd/commit/a3c4eb07106b29f7366113764cb1c8c4d6dd5646. Those two patches are just too invasive to backport for such a small convenience fix.


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