Clockwork

res_service(5)

NAME

res_service - Clockwork Resource Type for system init services

DESCRIPTION

The service resource manages system services, normally found in /etc/init.d. It can be used to restart or reload services in response to other system configuration changes through explicit dependencies. It can also be used to enable or disable specific services on boot.

To manage boot-time services, Clockwork relies on the native service management tools like chkconfig. The following tools are currently supported:

invoke-rc.d

For Debian and Ubuntu

chkconfig

For RedHat / CentOS

ATTRIBUTES

name
service

The name of the service, derived from its init script name in /etc/init.d.

running
stopped

Whether or not the service should be alive and running. Valid values are "yes" and "no". There is no default value; if not specified, Clockwork will not inspect the running state of the service.

Which attribute you use is a matter of personal preference.

running = "yes" has the same meaning as stopped = "no"

running = "no" has the same meaning as stopped = "yes"

enabled
disabled

Whether or not the service should be started at boot. Valid values are "yes" and "no". There is no default value; if not specified, Clockwork will not inspect the boot-state of the service.

Which attribute you use is a matter of personal preference.

enabled = "yes" has the same meaning as disabled = "no"

enabled = "no" has the same meaning as disabled = "yes"

EXAMPLES

Starting and Enabling Services

To ensure that SSH is running, and that it will automatically start when the system boots:

service "sshd" {
    running: "yes"
    enabled: "yes"
}

If you are of a pessimistic persuasion, you can use double negatives to accomplish the same thing:

service "sshd" {
    stopped:  "no"
    disabled: "no"
}

Stopping and Disabling Services

To ensure that avahi never runs, ever:

service "avahi-daemon" {
    running:  "no"
    disabled: "yes"
}

CAVEATS

1. Default Behavior

By default, Clockwork does nothing with services unless you tell it what to do. For example, this policy snippet is useless:

service "apache" { }

DEPENDENCIES

The service resource does not create implicit dependencies, but you can leverage explicit dependencies to reload services when their configuration changes.

For example, to restart syslog-ng when its global configuration file changes:

file "/etc/syslog-ng.conf" {
    # configuration omitted for clarity
}

service "syslog-ng" {
    running: "yes"
    enabled: "yes"
}

service("syslog-ng") depends on file("/etc/syslog-ng.conf")

Now, the syslog-ng service will be reloaded if Clockwork has to do anything to the /etc/syslog-ng.conf file.

AUTHOR

Clockwork was designed and written by James Hunt.

The Clockwork website is licensed under the Creative Commons Attribution-NoDerivs 3.0 United States License