Forge Home


Manage override files for LSB init.d boot dependencies.


45,596 latest version

5.0 quality score

We run a couple of automated
scans to help you access a
module's quality. Each module is
given a score based on how well
the author has formatted their
code and documentation and
modules are also checked for
malware using VirusTotal.

Please note, the information below
is for guidance only and neither of
these methods should be considered
an endorsement by Puppet.

Version information

  • 0.2.2 (latest)
  • 0.2.1
  • 0.2.0
  • 0.1.0
released Feb 4th 2018
This version is compatible with:
  • Puppet Enterprise 2018.1.x, 2017.3.x, 2017.2.x, 2017.1.x, 2016.5.x, 2016.4.x
  • Puppet >= 3.0.0 < 6.0.0
  • , , ,

Start using this module

  • r10k or Code Manager
  • Bolt
  • Manual installation
  • Direct download

Add this module to your Puppetfile:

mod 'stm-insserv_override', '0.2.2'
Learn more about managing modules with a Puppetfile

Add this module to your Bolt project:

bolt module add stm-insserv_override
Learn more about using this module with an existing project

Manually install this module globally with Puppet module tool:

puppet module install stm-insserv_override --version 0.2.2

Direct download is not typically how you would use a Puppet module to manage your infrastructure, but you may want to download the module in order to inspect the code.

Tags: boot, initd


stm/insserv_override — version 0.2.2 Feb 4th 2018


Build Status Puppet Forge License

Table of Contents

  1. Overview
  2. Module Description - What does the module do?
  3. Setup - The basics of getting started with gai
  1. Usage - Configuration options and additional functionality
  2. Reference - An under-the-hood peek at what the module is doing and how
  3. Limitations - OS compatibility, etc.
  4. Development - Guide for contributing to the module


Manage override files for LSB init.d boot dependencies.

Module description

The init.d boot process uses a dependency based order to start and stop services. Chapter 20 of the Linux Standard Base Core Specification 3.1 defines the format of a compliant Init Script. The Init Script for a service should include the necessary settings (e.g. the runlevels) to sucessfully start and stop the service. An override mechanism is available to allow local variations without modifying the distributed scripts. This requires the creation of files in the /etc/insserv/overrides directory. This module provides a way to manage these files in your environment.


What insserv_override affects

This module create, modifies or removes files in the /etc/insserv/overrides directory. These files are used to determine what services should run in a given runlevel and the order in which services are started or shut down.

Setup requirements

The insserv_override module requires the Puppetlabs modules stdlib version 4.3.x or later.

Beginning with insserv_override

The insserv_override module includes a defined type of the same name that creates override files in the proper location. It also calls the insserv executable to activate the new configuration.

You have to declare the type for each configuration you would like to override. See the next section for examples.


Update the Apache service configuration to only start in runlevel 2

insserv_override { 'apache2':
  default_start => [ '2' ],
  default_stop  => [ '0', '1', '3', '4', '5', '6' ],

Update dependencies for Puppet to be started last and terminated first

insserv_override { 'puppet':
  required_start => [ '$all' ],
  required_stop  => [ '$all' ],

Remove override for MySQL service

insserv_override { 'mysql':
  ensure => absent,


Defines Types

Public Defined Types

  • insserv_override: The main type to create or remove an override. Undefined parameters are not included in the override file.
Parameters (all optional)
  • ensure: Whether the override file should exist or not. This parameter is passed to the File resource. Default: present

  • provides: The names of the boot facilities provided by this script. Defaults to the resource title. Can be an array when more than one facility is provided.

  • required_start: The names of the facilities that must be available before this facility can be started. Can be a string or an array.

  • required_stop: The names of the facilities that must still be available when this facility is stopped. Can be a string or an array.

  • should_start: Facilities which should be available during startup of this facility. Can be a string or an array.

  • should_stop: Facilities which should still be available during shutdown of this facility. Can be a string or an array.

  • x_start_before: Facilities that should be started after the current facility. Can be a string or an array.

  • x_stop_after: Facilities that should be stopped before the current facility. Can be a string or an array.

  • default_start: The runlevels in which the current facility should be started.

  • default_stop: The runlevels in which the current facility should be stopped.

  • x_interactive: Whether to start this script alone during boot so the user can interact with it at the console. This is a boolean parameter. Default: false

  • short_description: A one-line description for the service.


This module is only useful on init.d based systems. Most modern distributions (e.g. Debian-8, Ubuntu-15.04, SLES-12, RedHat-7) are using the systemd boot process instead of the older init.d based boot process.


Feel free to send pull requests.