The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com

Feature #2712

Support start and stop priorities and runlevels for services

Added by Robert Foreman over 4 years ago. Updated 6 months ago.

Status:AcceptedStart date:10/10/2009
Priority:NormalDue date:
Assignee:Charlie Sharpsteen% Done:

0%

Category:service
Target version:-
Affected Puppet version:0.25.0 Branch:
Keywords: customer

We've Moved!

Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com

This ticket may be automatically exported to the PUP project on JIRA using the button below:


Description

Support start and stop priorities and runlevels for services.

  1. For RHEL it would involve managing the chkconfig line in the init script and using chkconfig reset.
  2. For Debian/Ubuntu this would be update-rc.d
  3. For Solaris/SMF this would be milestones and svcadm
  4. For runit this would be runsvchdir and sv

Related issues

Related to Puppet - Feature #738: Add runlevel functionality to service-resource for gentoo Rejected
Related to Puppet - Bug #15797: Redhat service provider does not respect chkconfig header... Closed 08/01/2012
Related to Puppet - Bug #16784: service resources will never converge under the RHEL6.x k... Needs More Information 10/04/2012
Duplicated by Puppet - Bug #13980: Services not disabling completely on RHEL 5/6 Duplicate 04/17/2012

History

#1 Updated by James Turnbull over 4 years ago

  • Category set to service
  • Status changed from Unreviewed to Needs More Information

I could have sworn there was a ticket for this already but…

So .. do you mean the run levels or the start and stop priority or both? I can’t remember if the chkconfig command overrides the information contained in the init script itself or vice versa – am assuming the command overrides it.

Also I guess whatever happens in Ubuntu and Upstart is a consideration too.

#2 Updated by Robert Foreman over 4 years ago

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.

#3 Updated by James Turnbull over 4 years ago

  • Subject changed from Add start/stop order for services to Support start and stop priorities and runlevels for services
  • Status changed from Needs More Information to Accepted

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.

#4 Updated by John Bollinger over 4 years ago

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.

#5 Updated by John Bollinger over 4 years ago

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.

#6 Updated by John Bollinger over 4 years ago

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",
}

#7 Updated by Nigel Kersten over 4 years ago

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….

#8 Updated by James Turnbull over 4 years ago

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.

#9 Updated by Markus Roberts over 4 years ago

  • Target version set to 0.25.3

#10 Updated by Luke Kanies over 4 years ago

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

#11 Updated by Markus Roberts over 4 years ago

  • Target version changed from 0.25.3 to 0.25.4

#12 Updated by James Turnbull over 4 years ago

  • Target version changed from 0.25.4 to 0.25.5

#13 Updated by James Turnbull about 4 years ago

  • Target version changed from 0.25.5 to 2.6.0

#14 Updated by Jesse Wolfe almost 4 years ago

  • Target version changed from 2.6.0 to 52

#15 Updated by James Turnbull about 3 years ago

  • Target version deleted (52)

#16 Updated by Ben Ford almost 2 years ago

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.

#17 Updated by Ken Johnson over 1 year ago

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

#18 Updated by Eric Seynaeve over 1 year ago

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

#19 Updated by Charlie Sharpsteen about 1 year ago

  • Assignee set to Charlie Sharpsteen

#20 Updated by Charlie Sharpsteen about 1 year ago

  • Keywords set to customer

Also available in: Atom PDF