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 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:
Embargoed:

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

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.