Unfortunately no, the chkconfig command does not override the init script. chkconfig uses the commented lines at the head of the init script to determine the appropriate run levels, start and stop priorities. We would need to manage this line from the sysv init script for the service followed by a chkconfig reset:

chkconfig: 2345 20 80 (start levels, start priority, stop priority)¶

For Ubuntu it looks like we would have to use update-rc.d or manage the symlinks directly. They are using upstart, but they are still using a sysv compatibility package. It looks like RHEL is also moving toward upstart, but I don’t know what that will mean for chkconfig yet.

I am primarily interested in managing the start/stop order, but in order to adequately manage start/stop priorities I think we would have to include levels.

Please note that fixing this issue may require more than managing the initscript headers. Initscript headers control the start/stop priorities, but not necessarily the runlevels for which the service is enabled. Here’s a summary of relevant chkconfig behaviors in RHEL 5 / CentOS 5 / at least some other RH variants:

chkconfig => enables / disables the service in runlevels 2, 3, 4, 5; does not manage runlevels 0, 1, or 6

chkconfig —level => enables / disables the service in the specified runlevels; does not manage other runlevels

chkconfig reset => enables / disables the service in all runlevels, according to the chkconfig header in the initscript

chkconfig —level reset => enables / disables the service in the specified runlevels, according tto the chkconfig header in the initscript

In a nutshell, if —level is omitted, then it defaults to 2345 for on / off, and to 0123456 for reset. Furthermore, relies on the initscript headers only for the start / stop priority, not for the levels in which the service runs.

Example: [jbolling@d100017 am]$ /sbin/chkconfig —list | grep setroubleshoot setroubleshoot 0:off 1:off 2:off 3:on 4:on 5:on 6:off

[jbolling@d100017 am]$ sudo /sbin/chkconfig setroubleshoot off [jbolling@d100017 am]$ /sbin/chkconfig —list | grep setroubleshoot setroubleshoot 0:off 1:off 2:off 3:off 4:off 5:off 6:off

[jbolling@d100017 am]$ sudo /sbin/chkconfig setroubleshoot on [jbolling@d100017 am]$ /sbin/chkconfig —list | grep setroubleshoot setroubleshoot 0:off 1:off 2:on 3:on 4:on 5:on 6:off

[jbolling@d100017 am]$ sudo /sbin/chkconfig setroubleshoot reset [jbolling@d100017 am]$ /sbin/chkconfig —list | grep setroubleshoot setroubleshoot 0:off 1:off 2:off 3:on 4:on 5:on 6:off

[jbolling@d100017 am]$ sudo /sbin/chkconfig —level 1 setroubleshoot on [jbolling@d100017 am]$ /sbin/chkconfig —list | grep setroubleshoot setroubleshoot 0:off 1:on 2:off 3:on 4:on 5:on 6:off

[jbolling@d100017 am]$ sudo /sbin/chkconfig setroubleshoot reset [jbolling@d100017 am]$ /sbin/chkconfig —list | grep setroubleshoot setroubleshoot 0:off 1:off 2:off 3:on 4:on 5:on 6:off

[jbolling@d100017 am]$ sudo /sbin/chkconfig —level 1 setroubleshoot on [jbolling@d100017 am]$ /sbin/chkconfig —list | grep setroubleshoot setroubleshoot 0:off 1:on 2:off 3:on 4:on 5:on 6:off

[jbolling@d100017 am]$ sudo /sbin/chkconfig —level 2345 setroubleshoot reset [jbolling@d100017 am]$ /sbin/chkconfig —list | grep setroubleshoot setroubleshoot 0:off 1:on 2:off 3:on 4:on 5:on 6:off

It would be entirely possible — and to me, preferable — for the provider to manage a service’s runlevels without touching its init script.

Please note also that there are problems in general with the service.enable property for systems that use runlevels. On those systems the property logically should have an array value, not a scalar value: the service is either enabled or disabled (or not configured) separately for each runlevel. This manifests in some minor weirdness when the redhat provider checks for service enablement via chkconfig, for the result is true if and only if the service is configured to run in the current runlevel, whatever that happens to be. The current runlevel in that case will normally be the one that most matters, but the door is open for Puppet to behave surprisingly here.

James Turnbull wrote:

I am happpy to include as a potential feature. It shouldn’t be too hard to come up with generic attributes and a feature to support start/stop priorities and runlevels.

May I suggest that runlevels be supported by extending the values understood for the “enable” property? That could simultaneously address the deficiency in Service’s current model for that property (that it’s a scalar, not an array). It is not necessary to make it accept an actual Puppet array value (though that could work); it would be sufficient for it to accept a digit string indicating in exactly which levels the service should be enabled.

Example:

service { "sshd":
    # The SSH daemon is enabled in runlevels 3, 4, and 5,
    # and disabled in all other runlevels:
    enable => "345",
}

We need to do something here, either adding a runlevel attribute to the Service type or extending the enable property.

I think I’m more in favour of adding extra attributes than overloading the existing ones.

I’m at the Ubuntu Developer Summit at the moment, and a lot of people are asking about upstart support in Puppet….

Well Puppet will work fine with Upstart now – the same tools are used to make changes and it should be transparent.

The next stage is managing the relationships between services that Upstart allows – that’s going to be interesting.

I also agree we shouldn’t overload existing attributes and should add some new ones.

Isn’t this a feature? If so, shouldn’t it be held for the next major release (i.e., rowlf)?

What is the status of this issue? The question of how to alter priorities and run levels has come up in each of the last three trainings I’ve done.

Is there anything new on this? I have a customer inquiry into the status of this issue.

According to me, it should be preferable to indicate the runlevel directly, overriding the defaults given in the init script. This would avoid having to parse/modify it.

Also, besides the #chkconfig line, the is also the LSB way of indicating runlevels which gets priority over the #chkconfig line on RHEL. This problem is also sidestepped when setting the runlevel directly.

Of course, upstart (RHEL6) and systemd (RHEL7 ?) make this a bit more complex.

Eric