Uploaded image for project: 'Puppet'
  1. Puppet
  2. PUP-1788

The service type should be able to use a script's default runlevels

    Details

    • Type: Improvement
    • Status: Accepted
    • Priority: Normal
    • Resolution: Unresolved
    • Affects Version/s: PUP 3.2.2, PUP 4.9.4
    • Fix Version/s: None
    • Component/s: None
    • Template:
    • Team:
      Platform OS

      Description

      Right now, with the redhat provider (and possibly others) using enable => true on service runs chkconfig servicename on which sets the service to be on in runlevels 2-5, if not currently enabled. It doesn't check the header of the init script to find out what runlevels it should be on for.

      Even though the comments in the code suggest that this is what's happening:

      lib/puppet/provider/service/redhat.rb

      36:  # Don't support them specifying runlevels; always use the runlevels
      37:  # in the init scripts.
      38:  def enable
      39:      chkconfig(@resource[:name], :on)
      

      In fact it's a little worse than that since chkconfig servicename exits with 0 (success) if the service is enabled in the current runlevel, it doesn't check any other runlevels. So if a service is off in all runlevels except 3, and the system is currently running in 3, then puppet will think it's already enabled and won't turn it on in 2-5 like it would otherwise.

      On top of that, if a service is missing a symlink under one of the /etc/rc*.d directories, chkconfig treats the service as being 'off' in that level. If you run chkconfig servicename on, it only creates the start symlinks under /etc/rc{2-5}.d/ it doesn't create the stop/kill symlinks under the other directories where they might be missing. This lead to an issue for us on shutdown: the network service was stopped prior to another service that used networking. When that service was eventually stopped, it just blocked and never exited. Adding a stop/kill symlink for that service in all the other runlevel directories (which chkconfig servicename reset does) fixed the problem.

      I'm actually not sure if it's better to change the behavior of enable => true to run chkconfig servicename reset or to leave that behavior alone and let enable take another value like auto which has the new behavior.

        Attachments

          Issue Links

            Activity

              jsd-sla-details-panel

                People

                • Assignee:
                  Unassigned
                  Reporter:
                  swillis@compete.com Steven Willis
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  3 Start watching this issue

                  Dates

                  • Created:
                    Updated: