Bug 702003 - chkconfig --level N servicename returns wrong information
chkconfig --level N servicename returns wrong information
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: chkconfig (Show other bugs)
15
Unspecified Unspecified
urgent Severity unspecified
: ---
: ---
Assigned To: Bill Nottingham
Fedora Extras Quality Assurance
RejectedBlocker, RejectedNTH
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-05-04 10:13 EDT by Simo Sorce
Modified: 2014-03-16 23:27 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-08-07 15:14:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Simo Sorce 2011-05-04 10:13:34 EDT
For services that have been migrated to systemd chkconfig returns wrong information.

I have a machine that I upgraded for older chkconfg/systemd/etc.. versions and when I ask for information about ntpd I get wrong information

ntpd was originally configured to start at level 2,3,4,5 and not 1,6 as normal.

now when you try to ask information about it with chkconfig --level I get stale info.

Tests:

$ for i in 1 2 3 4 5 6; do chkconfig ntpd --level $i; echo $i: $?; done
1:1
2:0
3:0
4:0
5:0
6:1
$ chkconfig ntpd off
(fwd to systemctl and ntpd.service link is removed
$ for i in 1 2 3 4 5 6; do chkconfig ntpd --level $i; echo $i: $?; done
1:1
2:0
3:0
4:0
5:0
6:1

As you can see even if the service was disabled the information is still the same (and symlinks to start/stop ntpd under rc3.d rc4.d rc5.d are still there).



Expected behavior:
chkconfig <service> off should properly remove rcX.d links for services that have been migrated to systemd
chkconfig --level X ntpd should return information from systemd for services managed by systemd (it's ok to return on/off the same way for all levels 2,3,4,5 as long as that reflect the actual enabled/disabled status in systemd)


We use chkconfig --level to test if ntpd (and other services) are enabled/disabled in the ipa install script and this makes it receive bogus information causing it to not be able to properly detect system status.
Comment 1 Michal Schmidt 2011-05-04 14:17:52 EDT
I could not find where freeipa uses chkconfig with the --level option. I only found a use of the --list option in the function is_enabled in ipaserver/install/service.py ( http://git.fedorahosted.org/git/?p=freeipa.git;a=blob;f=ipaserver/install/service.py;h=1ebd96d7b48a8d8d1df41950da517e18383f2d9c;hb=HEAD#l75 )

Instead of parsing the output of --list, could the function is_enabled be simplified to run "chkconfig SERVICE" and only test the exit code?
That should work fine once bug 699027 is fixed.
Comment 2 Simo Sorce 2011-05-04 15:19:08 EDT
The patch to stop using --list and instead using --level is already on the freeipa-devel list, it will be pushed into the f15 soon.

The bug was found indeed while I was working on stopping using --list ..
Comment 3 Michal Schmidt 2011-05-04 15:49:41 EDT
I see. So the new code is a Python equivalent of:

chkconfig --level 3 $SERVICE &&
 chkconfig --level 4 $SERVICE &&
 chkconfig --level 5 $SERVICE

Why not just "chkconfig $SERVICE" (which would get forwarded to "systemctl is-enabled $SERVICE.service" for native systemd services)?

(In reply to comment #0)
> Expected behavior:
...
> chkconfig --level X ntpd should return information from systemd for services
> managed by systemd (it's ok to return on/off the same way for all levels
> 2,3,4,5 as long as that reflect the actual enabled/disabled status in systemd)

Some packages' %triggerun scripts depend on "chkconfig --level X foobar" not being redirected to systemctl (as in http://0pointer.de/public/systemd-man/daemon.html ).
Comment 4 Simo Sorce 2011-05-04 15:58:41 EDT
chkconfig $SERVICE tells you only if the service exists, doesn't tell you anything about whether it is enabled or not.
Specifically returning 1 from chkconfig SERVICE because the service is disabled but exists would be a bug.
Comment 5 Michal Schmidt 2011-05-04 16:02:21 EDT
The chkconfig manpage on RHEL5 says:

If only a service name is given, it checks to see if the service
is  configured to be started in the current runlevel. If it is, chkcon-
fig returns true; otherwise it returns false.
Comment 6 Bill Nottingham 2011-05-04 16:10:08 EDT
<deletes comment> - What Michal said.

> chkconfig --level X ntpd should return information from systemd for services
> managed by systemd (it's ok to return on/off the same way for all levels
> 2,3,4,5 as long as that reflect the actual enabled/disabled status in systemd)

The problem here is that someone will then complain about it when they have some other mapping in systemd that doesn't correspond to this runlevel sort of definition, especially if the administrator starts creating their own targets and enables services there.
Comment 7 Simo Sorce 2011-05-04 16:58:00 EDT
(In reply to comment #5)
> The chkconfig manpage on RHEL5 says:
> 
> If only a service name is given, it checks to see if the service
> is  configured to be started in the current runlevel. If it is, chkcon-
> fig returns true; otherwise it returns false.

uhmm true .. I guess that's why --list was used before ... I will need to check on that ...
Comment 8 Simo Sorce 2011-05-04 17:03:09 EDT
(In reply to comment #6)
> <deletes comment> - What Michal said.
> 
> > chkconfig --level X ntpd should return information from systemd for services
> > managed by systemd (it's ok to return on/off the same way for all levels
> > 2,3,4,5 as long as that reflect the actual enabled/disabled status in systemd)
> 
> The problem here is that someone will then complain about it when they have
> some other mapping in systemd that doesn't correspond to this runlevel sort of
> definition, especially if the administrator starts creating their own targets
> and enables services there.

But if runlevels do not make any sense in a systemd owned service why should levels mean anything ?
Unless there is a mapping between targets and runlevels that is ...

What does it mean for a migrate service to be enabled in --level 3 ?
If it means actually something (thourgh a mapping of some sort) then fine return true only when that meaning is met, but if the level number can't be mapped then it seem to me that the best effort lies into returning whatever is true "now", as "now" is the only "runlevel" you can possibly map to.

Or am I getting something wrong here ?
Comment 9 Simo Sorce 2011-05-04 17:22:41 EDT
Ok after some thinking I think I can solve the problem in freeipa by simply using chkconfig SERVICE as Michal suggested, that's what we really want to do anyway currently.

So I can avoid the issue. I am not sure if it si right to close this bug though, as other may have legitimate reasons to use --level, and at the very least they shouldn't get back stale data as replies.
Comment 10 Bill Nottingham 2011-05-04 17:36:45 EDT
(In reply to comment #8)
> But if runlevels do not make any sense in a systemd owned service why should
> levels mean anything ?
> Unless there is a mapping between targets and runlevels that is ...

There is a mapping, roughly:

234 -> multi-user.target
5 -> graphical.target

However, this doesn't take into account:
- whether the admin was actually using runlevel 2 or 4 for something different
- whether the admin has decided on a different (custom?) target entirely

> What does it mean for a migrate service to be enabled in --level 3 ?
> If it means actually something (thourgh a mapping of some sort) then fine
> return true only when that meaning is met, but if the level number can't be
> mapped then it seem to me that the best effort lies into returning whatever is
> true "now", as "now" is the only "runlevel" you can possibly map to.
> 
> Or am I getting something wrong here ?

Not sure what you mean - if you want to check 'now', don't pass a level, yes.
(Of course, this could cause unpredictable behavior if it can't determine the current runlevel at all, or if the runlevel is single-user mode.)
Comment 11 Bill Nottingham 2011-05-04 17:37:43 EDT
There is a request to delete symlinks when disabling services in systemd; however, doing the converse is likely to break other things.

The simplest solution is likely to ship either only a sysv service file or a systemd service file in a pacakge, not both - this is likely the way the packaging guidelines will go.
Comment 12 James Laska 2011-05-05 07:29:38 EDT
simo: Given comment#9, are you still proposing this as a F15 release blocker?
Comment 13 Simo Sorce 2011-05-05 07:58:47 EDT
(In reply to comment #12)
> simo: Given comment#9, are you still proposing this as a F15 release blocker?

I guess this bug may not be a blocker anymore, but then bug 699027 should be as I depend on at least that behaviour to be correct.
Comment 14 James Laska 2011-05-06 09:46:32 EDT
For the upcoming blocker meeting, I can't find any criteria impacted by the presence of this issue, and it appears it can be safely addressed in a post-release update.  I have raised bug#699027 for discussion as a NTH.

-1 Blocker, -1 NTH
Comment 15 Tim Flink 2011-05-06 13:34:31 EDT
Discussed in the 2011-05-06 blocker review meeting. Rejected as F15 final blocker and NTH.

This does not clearly hit any release criteria, only affects services with both systemd and sysv definitionsand doesn't seem to have a significant enough impact for nth. Also, a relatively straightforward workaround is available
Comment 16 Fedora End Of Life 2012-08-07 15:14:53 EDT
This message is a notice that Fedora 15 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 15. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '15' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 15 reached 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 to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.

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.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

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