Forge Home


Puppet provider wrapping service resources making sure the service is really running


6,624 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

  • 1.0.3 (latest)
  • 1.0.2
  • 1.0.1
  • 1.0.0
  • 0.2.0
  • 0.1.2
  • 0.1.1
  • 0.1.0
released Aug 30th 2017
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.2.0 < 6.0.0
  • , ,

Start using this module

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

Add this module to your Puppetfile:

mod 'katello-service_wait', '1.0.3'
Learn more about managing modules with a Puppetfile

Add this module to your Bolt project:

bolt module add katello-service_wait
Learn more about using this module with an existing project

Manually install this module globally with Puppet module tool:

puppet module install katello-service_wait --version 1.0.3

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.



katello/service_wait — version 1.0.3 Aug 30th 2017

Puppet Forge Build Status


Wrapper around service control command making sure that the service is really running after start.


Imagine a simple process of setting up your web application, that includes:

  1. installing a database server
  2. starting the server
  3. preseeding the data

And now imagine, that service $DATABASE_SERVER start finishes but the service is still unavailable due to setup procedures. This happens with almost every network service.

Also, some services do not start or stop properly and return non-zero values for some commands.

This simple wrapper works with any service and just pass over the request to service controller, but for few problematic ones it waits until service is fully started or stopped.


Service-wait let's you specify what it means the service is running using a plugin architecture (with simple bash scripts).

Then, instead of service $DATABSE_SERVER start you use service-wait $DATABASE_SERVER start.


Now imagine that you want to automate the described setup process using Puppet. This library includes a Puppet provider for service resources that wraps the service-wait script so that you can reuse the existing puppet modules that make sure that the required services are really running.

Plugin anatomy

The plugins can be found in plugins directory (or specifying using $PLUGINS_DIR environment variable.

Here is an annotated example:

# REQUIRED: test so determine if this plugin is usable with given service
confine [ $SERVICE = 'tomcat6' -o $SERVICE = 'tomcat7' ]

# OPTIONAL: sometimes the service command fails even if the service
#           starts (some bug probably). This let's you to ignore the
#           exit code of the original service command and use your
#           criteria on determining whether the service is running or
#           not.

# this function gets loaded when the serivce is started/restarted and
# it should finish when the service is really running (performing some
# periodic checks on the status).
service-wait () {
    # the status can be determined by asking on some url
    wait-for-url http://localhost:3000
    # or the service listening on a port
    wait-for-port 3000
    # or some command to be successful
    wait-for-command serviceready

    # the status can be checked using $RETVAL variable
    if [ $RETVAL -eq 0 ]; then
       echo "success"

Supported OSes

Currently, service-wait is tested with RHEL/CentOS/Fedora distributions.


Copyright 2013 Red Hat, Inc. GPLv2