Adoptable Cookbooks List

Looking for a cookbook to adopt? You can now see a list of cookbooks available for adoption!
List of Adoptable Cookbooks

Supermarket Belongs to the Community

Supermarket belongs to the community. While Chef has the responsibility to keep it running and be stewards of its functionality, what it does and how it works is driven by the community. The chef/supermarket repository will continue to be where development of the Supermarket application takes place. Come be part of shaping the direction of Supermarket by opening issues and pull requests or by joining us on the Chef Mailing List.

Select Badges

Select Supported Platforms

Select Status


runit (70) Versions 1.7.8

Installs runit and provides runit_service resource

cookbook 'runit', '= 1.7.8', :supermarket
cookbook 'runit', '= 1.7.8'
knife supermarket install runit
knife supermarket download runit
Quality 0%

runit Cookbook

Installs runit and provides the runit_service service resource for managing processes (services) under runit.

This cookbook does not use runit to replace system init, nor are ther plans to do so.

For more information about runit:

A note regarding versions 1.7.0 and 1.7.2

With the benefit of hindsight we can say that the changes contained version 1.7.0 merited a major version number change, and that version 1.7.2 contains some still unresolved regressions compared to 1.6.0. Please be sure to test this new version for compatibility with your systems before upgrading to version 1.7.

See issue #144 for some notes on how these versions behaved unexpectedly in one user's environment.



  • Debian/Ubuntu
  • Gentoo
  • RHEL


  • Chef 11+


  • packagecloud (for RHEL)


See attributes/default.rb for defaults generated per platform.

  • node['runit']['sv_bin'] - Full path to the sv binary.
  • node['runit']['chpst_bin'] - Full path to the chpst binary.
  • node['runit']['service_dir'] - Full path to the default "services" directory where enabled services are linked.
  • node['runit']['sv_dir'] - Full path to the directory where service lives, which gets linked to service_dir.
  • node['runit']['lsb_init_dir'] - Full path to the directory where the LSB-compliant init script interface will be created.
  • node['runit']['start'] - Command to start the runsvdir service
  • node['runit']['stop] - Command to stop the runsvdir service
  • node['runit']['reload'] - Command to reload the runsvdir service

Optional Attributes for RHEL systems

  • node['runit']['prefer_local_yum'] - If true, assumes that a runit package is available on an already configured local yum repository. By default, the recipe installs the runit package from a Package Cloud repository (see below). This is set to the value of node['runit']['use_package_from_yum'] for backwards compatibility, but otherwise defaults to false.



The default recipe installs runit and starts runsvdir to supervise the services in runit's service directory (e.g., /etc/service).

On RHEL-family systems, it will install the runit RPM using Ian Meyer's Package Cloud repository for runit. This replaces the previous functionality where the RPM was build using his runit RPM SPEC. However, if the attribute node['runit']['prefer_local_yum'] is set to true, the packagecloud repository creation will be skipped and it is assumed that a runit package is available on an otherwise configured (outside this cookbook) local repository.

On Debian family systems, the runit packages are maintained by the runit author, Gerrit Pape, and the recipe will use that for installation.

On Gentoo, the runit ebuild package is installed.


This cookbook has a resource, runit_service, for managing services under runit. This service subclasses the Chef service resource.

This resource replaces the runit_service definition. See the file in this cookbook for breaking change information and any actions you may need to take to update cookbooks using runit_service.


  • enable - enables the service, creating the required run scripts and symlinks. This is the default action.
  • start - starts the service with sv start
  • stop - stops the service with sv stop
  • disable - stops the service with sv down and removes the service symlink
  • create - create the service directory, but don't enable the service with symlink
  • restart - restarts the service with sv restart
  • reload - reloads the service with sv force-reload
  • once - starts the service with sv once.
  • hup - sends the HUP signal to the service with sv hup
  • cont - sends the CONT signal to the service
  • term - sends the TERM signal to the service
  • kill - sends the KILL signal to the service
  • up - starts the service with sv up
  • down - downs the service with sv down
  • usr1 - sends the USR1 signal to the service with sv 1
  • usr2 - sends the USR2 signal to the service with sv 2

Service management actions are taken with runit's "sv" program.

Read the sv(8) man page for more information on the sv program.

Parameter Attributes

The first three parameters, sv_dir, service_dir, and sv_bin will attempt to use the corresponding node attributes, and fall back to hardcoded default values that match the settings used on Debian platform systems.

Many of these parameters are only used in the :enable action.

  • sv_dir - The base "service directory" for the services managed by the resource. By default, this will attempt to use the node['runit']['sv_dir'] attribute, and falls back to /etc/sv.
  • service_dir - The directory where services are symlinked to be supervised by runsvdir. By default, this will attempt to use the node['runit']['service_dir'] attribute, and falls back to /etc/service.
  • lsb_init_dir - The directory where an LSB-compliant init script interface will be created. By default, this will attempt to use the node['runit']['lsb_init_dir'] attribute, and falls back to /etc/init.d.
  • sv_bin - The path to the sv program binary. This will attempt to use the node['runit']['sv_bin'] attribute, and falls back to /usr/bin/sv.
  • service_name - Name attribute. The name of the service. This will be used in the directory of the managed service in the sv_dir and service_dir.
  • sv_timeout - Override the default sv timeout of 7 seconds.
  • sv_verbose - Whether to enable sv verbose mode. Default is false.
  • sv_templates - If true, the :enable action will create the service directory with the appropriate templates. Default is true. Set this to false if the service has a package that provides its own service directory. See Usage examples.
  • options - Options passed as variables to templates, for compatibility with legacy runit service definition. Default is an empty hash.
  • env - A hash of environment variables with their values as content used in the service's env directory. Default is an empty hash. When this hash is non-empty, the contents of the runit service's env directory will be managed by Chef in order to conform to the declared state.
  • log - Whether to start the service's logger with svlogd, requires a template sv-service_name-log-run.erb to configure the log's run script. Default is true.
  • default_logger - Whether a default log/run script should be set up. If true, the default content of the run script will use svlogd to write logs to /var/log/service_name. Default is false.
  • log_dir - The directory where the svlogd log service will run. Used when default_logger is true. Default is /var/log/service_name
  • log_size - The maximum size a log file can grow to before it is automatically rotated. See svlogd(8) for the default value.
  • log_num - The maximum number of log files that will be retained after rotation. See svlogd(8) for the default value.
  • log_min - The minimum number of log files that will be retained after rotation (if svlogd cannot create a new file and the minimum has not been reached, it will block). Default is no minimum.
  • log_timeout - The maximum age a log file can get to before it is automatically rotated, whether it has reached log_size or not. Default is no timeout.
  • log_processor - A string containing a path to a program that rotated log files will be fed through. See the PROCESSOR section of svlogd(8) for details. Default is no processor.
  • log_socket - An string containing an IP:port pair identifying a UDP socket that log lines will be copied to. Default is none.
  • log_prefix - A string that will be prepended to each line as it is logged. Default is no prefix.
  • log_config_append - A string containing optional additional lines to add to the log service configuration. See svlogd(8) for more details.
  • cookbook - A cookbook where templates are located instead of where the resource is used. Applies for all the templates in the enable action.
  • check - whether the service has a check script, requires a template sv-service_name-check.erb
  • finish - whether the service has a finish script, requires a template sv-service_name-finish.erb
  • control - An array of signals to customize control of the service, see runsv man page on how to use this. This requires that each template be created with the name sv-service_name-signal.erb.
  • supervisor_owner - the user that should be allowed to control this service, see runsv faq
  • supervisor_group - the group that should be allowed to control this service, see runsv faq
  • owner - user that should own the templates created to enable the service
  • group - group that should own the templates created to enable the service
  • run_template_name - alternate filename of the run run script to use replacing service_name.
  • log_template_name - alternate filename of the log run script to use replacing service_name.
  • check_script_template_name - alternate filename of the check script to use, replacing service_name.
  • finish_script_template_name - alternate filename of the finish script to use, replacing service_name.
  • control_template_names - a hash of control signals (see control above) and their alternate template name(s) replacing service_name.
  • status_command - The command used to check the status of the service to see if it is enabled/running (if it's running, it's enabled). This hardcodes the location of the sv program to /usr/bin/sv due to the aforementioned cookbook load order.
  • restart_on_update - Whether the service should be restarted when the run script is updated. Defaults to true. Set to false if the service shouldn't be restarted when the run script is updated.
  • start_down - Set the default state of the runit service to 'down' by creating <sv_dir>/down file. Defaults to false. Services using start_down will not be notified to restart when their run script is updated.
  • delete_downfile - Delete previously created <sv_dir>/down file

Unlike previous versions of the cookbook using the runit_service definition, the runit_service resource can be notified. See Usage examples below.


To get runit installed on supported platforms, use recipe[runit]. Once it is installed, use the runit_service resource to set up services to be managed by runit.

In order to use the runit_service resource in your cookbook(s), each service managed will also need to have sv-service_name-run.erb and sv-service_name-log-run.erb templates created. If the log parameter is false, the log run script isn't created. If the log parameter is true, and default_logger is also true, the log run
script will be created with the default content:

exec svlogd -tt /var/log/service_name


These are example use cases of the runit_service resource described above. There are others in the runit_test cookbook that is included in the git repository.

Default Example

This example uses all the defaults in the :enable action to set up the service.

We'll set up chef-client to run as a service under runit, such as is done in the chef-client cookbook. This example will be more simple than in that cookbook. First, create the required run template, chef-client/templates/default/sv-chef-client-run.erb.

exec 2>&1
exec /usr/bin/env chef-client -i 1800 -s 30

Then create the required log/run template, chef-client/templates/default/sv-chef-client-log-run.erb.

exec svlogd -tt ./main

Note This will cause output of the running process to go to /etc/sv/chef-client/log/main/current. Some people may not like this, see the following example. This is preserved for compatibility reasons.

Finally, set up the service in the recipe with:

runit_service "chef-client"

Default Logger Example

To use a default logger with svlogd which will log to /var/log/chef-client/current, instead, use the default_logger option.

runit_service "chef-client" do
  default_logger true

No Log Service

If there isn't an appendant log service, set log to false, and the log/run script won't be created.

runit_service "no-svlog" do
  log false

Check Script

To create a service that has a check script in its service directory, set the check parameter to true, and create a sv-checker-check.erb template.

runit_service "checker" do
  check true

This will create /etc/sv/checker/check.

Finish Script

To create a service that has a finish script in its service directory, set the finish parameter to true, and create a sv-finisher-finish.erb template.

runit_service "finisher" do
  finish true

This will create /etc/sv/finisher/finish.

Alternate service directory

If the service directory for the managed service isn't the sv_dir (/etc/sv), then specify it:

runit_service "custom_service" do
  sv_dir "/etc/custom_service/runit"

No Service Directory

If the service to manage has a package that provides its service directory, such as git-daemon on Debian systems, set sv_templates to false.

package "git-daemon-run"

runit_service "git-daemon" do
  sv_templates false

This will create the service symlink in /etc/service, but it will not manage any templates in the service directory.

User Controlled Services

To set up services controlled by a non-privileged user, we follow the recommended configuration in the runit documentation (Is it possible to allow a user other than root to control a service?).

Suppose the user's name is floyd, and floyd wants to run floyds-app. Assuming that the floyd user and group are already managed with Chef, create a runsvdir-floyd runit_service.

runit_service "runsvdir-floyd"

Create the sv-runsvdir-floyd-log-run.erb template, or add log false. Also create the sv-runsvdir-floyd-run.erb with the following content:

exec 2>&1
exec chpst -ufloyd runsvdir /home/floyd/service

Next, create the runit_service resource for floyd's app:

runit_service "floyds-app" do
  sv_dir "/home/floyd/sv"
  service_dir "/home/floyd/service"
  owner "floyd"
  group "floyd"

And now floyd can manage the service with sv:

$ id
uid=1000(floyd) gid=1001(floyd) groups=1001(floyd)
$ sv stop /home/floyd/service/floyds-app/
ok: down: /home/floyd/service/floyds-app/: 0s, normally up
$ sv start /home/floyd/service/floyds-app/
ok: run: /home/floyd/service/floyds-app/: (pid 5287) 0s
$ sv status /home/floyd/service/floyds-app/
run: /home/floyd/service/floyds-app/: (pid 5287) 13s; run: log: (pid 4691) 726s


Next, let's set up memcached under runit with some additional options using the options parameter. First, the memcached/templates/default/sv-memcached-run.erb template:

exec 2>&1
exec chpst -u <%= @options[:user] %> /usr/bin/memcached -v -m <%= @options[:memory] %> -p <%= @options[:port] %>

Note that the script uses chpst (which comes with runit) to set the user option, then starts memcached on the specified memory and port (see below).

The log/run template, memcached/templates/default/sv-memcached-log-run.erb:

exec svlogd -tt ./main

Finally, the runit_service in our recipe:

runit_service "memcached" do
    :memory => node[:memcached][:memory],
    :port => node[:memcached][:port],
    :user => node[:memcached][:user]

This is where the user, port and memory options used in the run template are used.

Notifying Runit Services

In previous versions of this cookbook where the definition was used, it created a service resource that could be notified. With the runit_service resource, recipes need to use the full resource name.

For example:

runit_service "my-service"

template "/etc/my-service.conf" do
  notifies :restart, "runit_service[my-service]"

Because the resource implements actions for various commands that sv can send to the service, any of those actions could be used for notification. For example, chef-client supports triggering a Chef run with a USR1 signal.

template "/tmp/chef-notifier" do
  notifies :usr1, "runit_service[chef-client]"

For older implementations of services that used runit_service as a definition, but may support alternate service styles, use a conditional, such as based on an attribute:

service_to_notify = case node['nginx']['init_style']
                    when "runit"

template "/etc/nginx/nginx.conf" do
  notifies :restart, service_to_notify

More Examples

For more examples, see the runit_test cookbook's service recipe in the git repository.

License & Authors

Copyright:: 2008-2016, Chef Software, Inc

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
See the License for the specific language governing permissions and
limitations under the License.

Dependent cookbooks

packagecloud >= 0.0.0

Contingent cookbooks

activemq Applicable Versions
anaconda Applicable Versions
apache_kafka Applicable Versions
apache_tomcat Applicable Versions
application Applicable Versions
application_ruby Applicable Versions
artifactory Applicable Versions
artifactory_ii Applicable Versions
berkshelf Applicable Versions
berkshelf-api Applicable Versions
berkshelf-api-server Applicable Versions
bjn_logstash Applicable Versions
bootstrap Applicable Versions
btm-test Applicable Versions
camo Applicable Versions
carbon Applicable Versions
carton Applicable Versions
cassandra Applicable Versions
cassandra-priam Applicable Versions
celery-flower Applicable Versions
chef Applicable Versions
chef-client-runit Applicable Versions
chef-server Applicable Versions
chef_nginx Applicable Versions
chefgithook Applicable Versions
chronos Applicable Versions
cobbler Applicable Versions
confluence Applicable Versions
consul Applicable Versions
consul-template Applicable Versions
copy_filebeat_registry Applicable Versions
crowd Applicable Versions
current Applicable Versions
cyclesafe_chef Applicable Versions
dima-repose Applicable Versions
distsync Applicable Versions
djbdns Applicable Versions
dkron Applicable Versions
docker Applicable Versions
docker_registry Applicable Versions
dusk Applicable Versions
dynomite Applicable Versions
elasticsearch_cluster Applicable Versions
elkstack Applicable Versions
ellk Applicable Versions
enstratius_agent_proxy Applicable Versions
enterprise Applicable Versions
et_elk Applicable Versions
exabgp Applicable Versions
exhibitor Applicable Versions
fanfare Applicable Versions
filebeat Applicable Versions
flume Applicable Versions
foreflight_build_agent Applicable Versions
frog Applicable Versions
ganglia Applicable Versions
ganglia_cluster Applicable Versions
gce_gcsfuse Applicable Versions
gce_mysql_proxy Applicable Versions
gdash Applicable Versions
gem_server Applicable Versions
ghost Applicable Versions
git Applicable Versions
gitpaste Applicable Versions
glassfish Applicable Versions
god Applicable Versions
goiardi Applicable Versions
graphite Applicable Versions
graphite_lwrp Applicable Versions
graphiti Applicable Versions
hadoop_cluster Applicable Versions
haproxy_lwrp Applicable Versions
hbase_cluster Applicable Versions
hubot Applicable Versions
infochimps_graphite Applicable Versions
infochimps_statsd Applicable Versions
instrumental Applicable Versions
jackal Applicable Versions
jenkins Applicable Versions
jenkins_jnlp_slave Applicable Versions
jira Applicable Versions
kafka Applicable Versions
kibana5-gm Applicable Versions
kibana_lwrp Applicable Versions
kimchi Applicable Versions
lifeguard Applicable Versions
lita Applicable Versions
locustio Applicable Versions
logstash Applicable Versions
mailhog Applicable Versions
marathon Applicable Versions
memcached Applicable Versions
metarepo Applicable Versions
minecraft Applicable Versions
mogilefs Applicable Versions
mongodb Applicable Versions
mongodb3 Applicable Versions
mumble_server Applicable Versions
murmur Applicable Versions
nexus Applicable Versions
nginx Applicable Versions
nginx_simplecgi Applicable Versions
node Applicable Versions
nsq Applicable Versions
oc-id Applicable Versions
open_resty Applicable Versions
ops_tcpdump_handler Applicable Versions
paramount Applicable Versions
pen Applicable Versions
piwik Applicable Versions
poise-service-runit Applicable Versions
prometheus Applicable Versions
prose Applicable Versions
push-jobs Applicable Versions
rackbox Applicable Versions
railsbox Applicable Versions
rc_mon Applicable Versions
redis Applicable Versions
redis2 Applicable Versions
redmine2 Applicable Versions
repmgr Applicable Versions
resque Applicable Versions
riemann2 Applicable Versions
rocketchat Applicable Versions
rundeck Applicable Versions
scollector Applicable Versions
sensu_admin Applicable Versions
sentry Applicable Versions
simple-cerebro Applicable Versions
simple-hazelcast Applicable Versions
simple-kibana Applicable Versions
simple-logstash Applicable Versions
spark-jobserver Applicable Versions
statsite Applicable Versions
stompserver Applicable Versions
storm Applicable Versions
subrosa Applicable Versions
supermarket Applicable Versions
taskwarrior Applicable Versions
tasseo Applicable Versions
taurus Applicable Versions
teamspeak3 Applicable Versions
treslek Applicable Versions
uwsgi Applicable Versions
vsts_build_agent Applicable Versions
wombat-oam Applicable Versions
xldeploy Applicable Versions
xlrelease Applicable Versions
zookeeper Applicable Versions
zookeeper_cluster Applicable Versions
zookeeperd Applicable Versions

runit Cookbook CHANGELOG

This file is used to list changes made in each version of the runit cookbook.



  • Add missing goals to Debian init script template (#175)
  • Enhancement: Mark env files as sensitive (#182)
  • Reduce warning spam in Chef ~12.7 (#183)
  • Enhancement: Add support for specifying supervising user and/or group for managing service (#187)


  • Ensure supervise/ok named pipe is properly removed when disabling a service, so that it can be enabled again (#166, #167, #172)
  • Restore restart_on_update functionality originally added in #20 and lost in the 1.7.0 refactor.
  • Update test cookbooks to fix broken tests revealed by restoring restart_on_update functionality. Now using socat instead of netcat.

v1.7.4 (2015-10-13)

  • Ensure the service directory exists so that we will succeed when enabling services (#153)
  • Fix regression where env directory contents were being deleted when the env attribute is empty. (#144, #158)
  • Add log_dir attribute, used only when default_logger is true. (#135)
  • Ensure svlogd configuration is linked into correct path (#83, #135)
  • Update README and CHANGELOG for v1.7.0 to warn against known regressions (#144, #157)
  • Avoid mutating resource options for Chef 12 compatability (#147, #150, #156)
  • Fix regression regarding waiting for the service socket before running (#138, #142)
  • Reimplement idempotence checks for runit_service resources (#137, #141)
  • Enhance ChefSpec unit test coverage with specs that step into the LWRP (#139)
  • Deduplicate ServerSpec integration test coverage using example groups (#140)

v1.7.2 (2015-06-19)

  • Re-add missing runit_service actions start, stop, reload and status

v1.7.0 (2015-06-18)

NOTE: With the benefit of hindsight we can say that the changes contained in
this release merit a major version number change. Please be sure to test this
new version for compatibility with your systems before upgrading to version 1.7.

  • Modernize runit_service provider by rewriting pure Ruby as LWRP (#107)
  • Modernize integration tests by rewriting Minitest suites as ServerSpec (#107)
  • Fix regression in support for alternate sv binary on debian platforms (#92, #123)
  • Fix regression in default logger's config location (#117)
  • Tighten permissions on environment variable config files from 0644 to 0640 (#125)
  • Add start_down and delete_downfile attributes to support configuring services with default state of 'down' (#105)

v1.6.0 (2015-04-06)

  • Fedora 21 support
  • Kitchen platform updates
  • use imeyer’s packagecloud repo for RHEL
  • fix converge_by usage
  • do_action helper to set updated_by_last_action
  • style fixes to provider

v1.5.18 (2015-03-13)

  • Add helper methods to detect installation presence

v1.5.16 (2015-02-11)

  • Allow removal of env files(nhuff)

v1.5.14 (2015-01-15)

  • Provide create action(clako)

v1.5.12 (2014-12-15)

  • prevent infinite loop inside docker container
  • runit service failing inside docker container
  • move to librarian-chef for kitchen dependency resolution
  • update tests
  • updates to chefspec matchers

v1.5.10 (2014-03-07)

PR #53- Fix runit RPM file location for Chef provisionless Centos 5.9 Box Image


Fix runit RPM file location for Chef provisionless Centos 5.9 Box Image


Fixing string interpolation bug


Fixing assignment/compare error



  • COOK-3950 - runit cookbook should use full service path when checking running status



  • **[COOK-3267] - Improve testing suite in runit cookbook
  • Updating test-kitchen harness
  • Cleaning up style for rubocop


fixing metadata version error. locking to < 3.0


Locking yum dependency to '< 3'


[COOK-3560] Allow the user to configure runit's timeout (-w) and verbose (-v) settings




  • COOK-3271 - Fix an issue where runit fails to install rpm package on rehl systems


New Feature

  • COOK-3243 - Expose LSB init directory as a configurable


  • COOK-3182 - Do not hardcode rpmbuild location


  • COOK-3175 - Add svlogd config file support
  • COOK-3115 - Add ability to install 'runit' package from Yum



  • [COOK-2353]: Runit does not update run template if the service is already enabled
  • [COOK-3013]: Runit install fails on rhel if converge is only partially successful



  • [COOK-2549]: cannot enable_service (lwrp) on Gentoo
  • [COOK-2567]: Runit doesn't start at boot in Gentoo
  • [COOK-2629]: runit tests have ruby 1.9 method chaning syntax
  • [COOK-2867]: On debian, runit recipe will follow symlinks from /etc/init.d, overwrite /usr/bin/sv


  • [COOK-2477] - runit cookbook should enable EPEL repo for CentOS 5
  • [COOK-2545] - Runit cookbook fails on Amazon Linux
  • [COOK-2322] - runit init template is broken on debian


  • [COOK-2353] - Runit does not update run template if the service is already enabled
  • [COOK-2497] - add :nothing to allowed actions


  • [COOK-2404] - allow sending sigquit
  • [COOK-2431] - gentoo - it should create the runit-start template before calling it


  • [COOK-2351] - add run_template_name to allow alternate run script template


  • [COOK-2299] - runit_service resource does not properly start a non-running service


  • [COOK-2254] - (formerly CHEF-154) Convert runit_service definition to a service resource named runit_service.

This version has some backwards incompatible changes (hence the major
version bump). It is recommended that users pin the cookbook to the
previous version where it is a dependency until this version has been
tested in a non-production environment (use version 0.16.2):

depends "runit", "<= 0.16.2"

If you use Chef environments, pin the version in the appropriate

Changes of note

  1. The "runit" recipe must be included before the runit_service resource can be used.
  2. The runit_service definition created a separate service resource for notification purposes. This is still available, but the only actions that can be notified are :start, :stop, and :restart.
  3. The :enable action blocks waiting for supervise/ok after the service symlink is created.
  4. User-controlled services should be created per the runit documentation; see for an example.
  5. Some parameters in the definition have changed names in the resource. See below.

The following parameters in the definition are renamed in the resource
to clarify their intent.

  • directory -> sv_dir
  • active_directory -> service_dir
  • template_name -> use service_name (name attribute)
  • nolog -> set "log" to false
  • start_command -> unused (was previously in the "service" resource)
  • stop_command -> unused (was previously in the "service" resource)
  • restart_command -> unused (was previously in the "service" resource)


  • [COOK-1576] - Do not symlink /etc/init.d/servicename to /usr/bin/sv on debian
  • [COOK-1960] - default_logger still looks for sv-service-log-run template
  • [COOK-2035] - runit README change


  • [COOK-794] default logger and no_log for runit_service definition
  • [COOK-1165] - restart functionality does not work right on Gentoo due to the wrong directory in the attributes
  • [COOK-1440] - Delegate service control to normal user


  • [COOK-1008] - Added parameters for names of different templates in runit

Foodcritic Metric

1.7.8 failed this metric

FC002: Avoid string interpolation where not required: /tmp/cook/902bf06034452545a7199775/runit/libraries/provider_runit_service.rb:286
FC004: Use a service resource to start and stop services: /tmp/cook/902bf06034452545a7199775/runit/recipes/default.rb:24
FC023: Prefer conditional attributes: /tmp/cook/902bf06034452545a7199775/runit/libraries/provider_runit_service.rb:183
FC023: Prefer conditional attributes: /tmp/cook/902bf06034452545a7199775/runit/libraries/provider_runit_service.rb:195
FC023: Prefer conditional attributes: /tmp/cook/902bf06034452545a7199775/runit/recipes/default.rb:45
FC048: Prefer Mixlib::ShellOut: /tmp/cook/902bf06034452545a7199775/runit/libraries/helpers.rb:54