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.
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.
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 ..
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 ).
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.
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.
<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.
(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 ...
(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 ?
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.
(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.)
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.
simo: Given comment#9, are you still proposing this as a F15 release blocker?
(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.
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
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
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