cookbook 'runit', '= 5.1.3'
runit
(70) Versions
5.1.3
-
-
5.1.7
-
5.1.6
-
5.1.5
-
5.1.4
-
5.1.3
-
5.1.2
-
5.1.1
-
5.1.0
-
5.0.1
-
5.0.0
-
4.3.1
-
4.3.0
-
4.2.0
-
4.1.2
-
4.1.1
-
4.1.0
-
4.0.4
-
4.0.3
-
4.0.2
-
4.0.1
-
4.0.0
-
3.0.6
-
3.0.5
-
3.0.4
-
3.0.3
-
3.0.2
-
3.0.1
-
3.0.0
-
2.0.0
-
1.8.0
-
1.7.8
-
1.7.6
-
1.7.4
-
1.7.2
-
1.7.0
-
1.6.0
-
1.5.18
-
1.5.16
-
1.5.14
-
1.5.12
-
1.5.10
-
1.5.8
-
1.5.5
-
1.5.3
-
1.5.1
-
1.5.0
-
1.4.6
-
1.4.4
-
1.4.0
-
1.3.0
-
1.2.0
-
1.1.6
-
1.1.4
-
1.1.2
-
1.1.0
-
1.0.6
-
1.0.4
-
1.0.2
-
1.0.0
-
0.16.2
-
0.16.0
-
0.15.0
-
0.14.2
-
0.14.1
-
0.14.0
-
0.13.0
-
0.12.0
-
0.11.0
-
0.8.0
-
0.7.0
Follow121
- 5.1.7
- 5.1.6
- 5.1.5
- 5.1.4
- 5.1.3
- 5.1.2
- 5.1.1
- 5.1.0
- 5.0.1
- 5.0.0
- 4.3.1
- 4.3.0
- 4.2.0
- 4.1.2
- 4.1.1
- 4.1.0
- 4.0.4
- 4.0.3
- 4.0.2
- 4.0.1
- 4.0.0
- 3.0.6
- 3.0.5
- 3.0.4
- 3.0.3
- 3.0.2
- 3.0.1
- 3.0.0
- 2.0.0
- 1.8.0
- 1.7.8
- 1.7.6
- 1.7.4
- 1.7.2
- 1.7.0
- 1.6.0
- 1.5.18
- 1.5.16
- 1.5.14
- 1.5.12
- 1.5.10
- 1.5.8
- 1.5.5
- 1.5.3
- 1.5.1
- 1.5.0
- 1.4.6
- 1.4.4
- 1.4.0
- 1.3.0
- 1.2.0
- 1.1.6
- 1.1.4
- 1.1.2
- 1.1.0
- 1.0.6
- 1.0.4
- 1.0.2
- 1.0.0
- 0.16.2
- 0.16.0
- 0.15.0
- 0.14.2
- 0.14.1
- 0.14.0
- 0.13.0
- 0.12.0
- 0.11.0
- 0.8.0
- 0.7.0
Installs runit and provides runit_service resource
cookbook 'runit', '= 5.1.3', :supermarket
knife supermarket install runit
knife supermarket download runit
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 there plans to do so.
For more information about runit:
NOTE: The 5.0 release of this cookbook requires the ChefSpec which shipped in the later versions of ChefDK 3. If you use this cookbook along with ChefSpec in your environment then you will need to upgrade to the latest version of ChefDK / Workstation to prevent spec failures.
Requirements
Platforms
- Debian/Ubuntu
- RHEL and derivatives
Chef
- Chef 14.0+
Cookbooks
- packagecloud (for RHEL)
- yum-epel (for RHEL)
Attributes
-
node['runit']['prefer_local_yum']
- Iftrue
, assumes that arunit
package is available on an already configured local yum repository. By default, the recipe installs therunit
package from a Package Cloud repository (see below). This is set to the value ofnode['runit']['use_package_from_yum']
for backwards compatibility, but otherwise defaults tofalse
.
Recipes
default
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.
Resource
This cookbook has a resource, runit_service
, for managing services under runit.
Actions
- 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
- reload_log - reloads the service's log service
-
once - starts the service with
sv once
. -
hup - sends the
HUP
signal to the service withsv 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 withsv 1
-
usr2 - sends the
USR2
signal to the service withsv 2
Service management actions are taken with runit's "sv
" program.
Read the sv(8)
man page for more information on the sv
program.
Properties
The first three properties, sv_dir
, service_dir
, and sv_bin
will attempt to use the legacy node attributes, and fall back to hardcoded default values that match the settings used on Debian platform systems.
Many of these properties 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 thenode['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 thenode['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
andservice_dir
. -
sv_timeout - Override the default
sv
timeout of 7 seconds. -
sv_verbose - Whether to enable
sv
verbose mode. Default isfalse
. -
sv_templates - If true, the
:enable
action will create the service directory with the appropriate templates. Default istrue
. Set this tofalse
if the service has a package that provides its own service directory. See Usage examples. - options - DEPRECATED - 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'senv
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 usesvlogd
to write logs to/var/log/service_name
. Default is false. -
log_dir - The directory where the
svlogd
log service will run. Used whendefault_logger
istrue
. Default is/var/log/service_name
-
log_flags - The flags to pass to the
svlogd
command. Used whendefault_logger
istrue
. Default is-tt
- 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 tofalse
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 tofalse
. Services usingstart_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.
Usage
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
property is false, the log run script isn't created. If the log
property is true, and default_logger
is also true, the log run script will be created with the default content:
#!/bin/sh exec svlogd -tt /var/log/service_name
Examples
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
.
#!/bin/sh 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
.
#!/bin/sh 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 end
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 end
Check Script
To create a service that has a check script in its service directory, set the check
property to true
, and create a sv-checker-check.erb
template.
runit_service "checker" do check true end
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
property to true
, and create a sv-finisher-finish.erb
template.
runit_service "finisher" do finish true end
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" end
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 end
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:
#!/bin/sh 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" end
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
Options
Next, let's set up memcached under runit with some additional options using the options
property. First, the memcached/templates/default/sv-memcached-run.erb
template:
#!/bin/sh 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
:
#!/bin/sh exec svlogd -tt ./main
Finally, the runit_service
in our recipe:
runit_service "memcached" do options({ :memory => node[:memcached][:memory], :port => node[:memcached][:port], :user => node[:memcached][:user] }.merge(params)) end
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]" end
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]" end
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" "runit_service[nginx]" else "service[nginx]" end template "/etc/nginx/nginx.conf" do notifies :restart, service_to_notify end
More Examples
For more examples, see the runit_test
cookbook's service
recipe in the git repository.
Development
You may use test kitchen with either the vagrant or docker drivers to run integration tests.
Note: When using the docker driver please ensure that the container you are using has a working init system, as runit expects to be started by init. In some cases, systemd may need to be run in privileged mode.
For instance, for ubuntu with upstart:
driver_config:
image: ubuntu-upstart:14.04
run_command: /sbin/init
For redhat derivatives:
driver_config:
image: dockerhub/image-with-systemd
run_command: /usr/sbin/init
privileged: true
License & Authors
- Author:: Adam Jacob adam@chef.io
- Author:: Joshua Timberman joshua@chef.io
- Author:: Sean OMeara sean@sean.io
Copyright:: 2008-2019, 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 http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
runit Cookbook CHANGELOG
This file is used to list changes made in each version of the runit cookbook.
5.1.3 (2020-02-26)
- Cookstyle fixes - @tas50
- Remove unnecessary Foodcritic comments - @tas50
- Add github actions testing - @tas50
- Remove Ubuntu 14.04 specs - @tas50
5.1.2 (2019-07-22)
- Fix options property not taking on the legacy default value - @tas50
- Disable FC009 in the package resource - @tas50
- Fix comment typo - @tas50
- Wire up the service to actually use the status_command property - @tas50
5.1.1 (2019-05-29)
- Add a new use_init_script_sv_link property - @tas50
- Test on Chef 14 and Chef 15 in Travis - @tas50
- Correct pass in the signal variable for the control config - @markan
- Remove Ubuntu 14.04 Kitchen tests - @tas50
5.1.0 (2019-04-25)
- Add a new reload_log action - @tas50
5.0.1 (2019-02-11)
- Resolve an undefined method error for sv_bin
- Fix the cookbook incorrectly requiring Chef 13 when it now actually requires Chef 14 due to the use of find_resource. Sorry about this everyone.
5.0.0 (2019-02-04)
- This cookbook now requires Chef 13 or later. If you are still using Chef 12 please pin to the 4.3.1 release, and also seriously consider upgrading to the latest Chef to receive new features, bug fixes, and security updates in Chef.
- Performed a large-scale refactor of the resource to use the Chef resource DSL which resolves multiple edge case bugs by natively setting up properties, default values, and overrides
- Updated the default recipe to support Amazon Linux 2
- Default attributes used by the resource have been removed from the attributes file. They will continue to work, but their usage should be heavily discouraged as this mixed attributes + properties and results in confusion on where values come from.
- Formally deprecated the legacy
options
property in the readme - Removed some legacy backwards compatibility code for older Chef releases we no longer support
- Fixed broken integratino tests so we can better test this cookbook
- Added Amazon Linux 2 and Ubuntu 18.04 testing in Travis
- Consolidated mutliple helper methods into the resource itself for clarity
4.3.1 (2019-01-14)
- Fixing plat_specific_sv_name logic to work with Amazon Linux 2 - @mbaitelman
4.3.0 (2018-07-24)
- Fixing plat_specific_sv_name logic to work with Amazon Linux 2
- Fixing upstart logic to work with older Amazon versions
4.2.0 (2018-07-24)
- Don't double start when creating new services
- Quoting the timeout value prevents it being cast to an unsigned long.
- Add a new log_flags property for changing the default -tt logging flag
4.1.2 (2018-07-18)
- Make Ubuntu the same as Debian where we template out a script instead of symlinking /etc/init.d/servicename to sv
4.1.1 (2018-04-26)
- Fix typo in an error message
4.1.0 (2018-04-19)
- Also install the runit-systemd package on newer Ubuntus
- Remove chefspec matchers since they're auto generated by ChefDK now
4.0.4 (2017-12-20)
- Amazon on Chef 12 fix and additional testing
- Add unit tests for each platform we support
- Remove the old attributes for controlling the service
4.0.3 (2017-11-29)
- Remove the custom resource implementation that leaked in and was causing chefspec failures on Chef 12
- Convert all the service suite integration tests to inspec
4.0.2 (2017-11-29)
- Don't fail on Debian 7 where the runsvdir init script doesn't exist
4.0.1 (2017-11-29)
- Fix compile failures that caused chefspec and runtime failures
- Enable amazon linux testing of the default recipe in Travis
4.0.0 (2017-11-24)
- Fail if we're on an unsupported platform in the main recipe instead of silently continuing
- Manage the actual runit service. Without this the runit service may not actually be started which means any service using runit won't actually start at boot
- Update the readme to not refer to providers and properly call the resource's property actual proeprties
- Add Debian testing to Travis
- Move file and templates out of the default dir since only Chef 11 needs this
- Use runit-systemd on Debian 9+ since runit package is actually designed for using runit as the main system init system
- Remove extra files from the test recipes
- Add a test for runit-systemd and use the process inspec resource
3.0.6 (2017-11-16)
- Test with Local Delivery instead of Rake
- Update apache2 license string
- Fully support Amazon Linux
3.0.5 (2017-01-25)
- Don’t mask errors from shellout helper if the binary is present.
- Don't error stopping a service that doesn't exist
3.0.4 (2017-01-24)
- Cookstyle fixes
- Update the cookbook description
- Check that chef_version exists before declaring it
3.0.3 (2016-12-07)
- Convert main suite test spec to inspec
- Add a number of debug statements to the provider to make debugging failed runs easier
- Fix faulty shell outs in the status commands that caused silent failures introduced in the 3.0.2 release
3.0.2 (2016-12-05)
- Remove unused helper method runit_sv_works?
- Use our new official Oracle images in Test Kitchen
- Update wording to clarify that we’re deleting not ‘zapping’ files
- Don’t hang forever if Runit isn’t installed when using the provider
- Check for the runit binary before every shellout
- Remove Fedora support since it doesn’t work
3.0.1 (2016-12-05)
- Set service to restart on env changes
3.0.0 (2016-09-16)
- Testing updates
- Require Chef 12.1+
2.0.0 (2016-08-30)
- Remove support for Gentoo as we have no way to test this
- Remove the empty library file
- Run specs against the latest RHEL 5
- Basic convergence testing in Travis CI
- Remove the need for apt in test kitchen
1.8.1 (2016-08-30)
- Enable runit installation in Oracle Linux systems
- Remove double oracle in the metadata
1.8.0
- Breaking change: Removed support for EOL Ubuntu platforms (i.e. versions 6.10, 7.04, 7.10, 8.04) (#194)
- Added a dependency on yum-epel for RHEL platforms
- Breaking change: Removed logic which skipped waiting for named pipe when running inside Docker (#193)
- This cookbook is now managed by the Chef Community team and is located at http://www.github.com/chef-cookbooks/runit
- Cookbook development is now occurring on the master branch with releases taking place after merging. The development branch will be removed
- Added a .foodcritic file to ignore FC004
- Updated platforms to test in the Test Kitchen file
- Replaced the Cheffile with a Berksfile
- Moved the specs to the specs directory and removed logic to detect the depsolver
- Replaced Rubocop with Cookstyle
- Added basic testing in Travis CI
- Silenced deprecation warnings in the Chefspecs and removed the Chef 12.5 pin that was used to do the same previously
- Added maintainers.md and maintainers.toml files
- Removed Gentoo as an officially supported platform as we're not testing this
- Added additional RHEL derivatives as supported platforms in metadata.rb
- Added chef_version, source_url, and issues_url metadata to metadata.rb
v1.7.8
- 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)
v1.7.6
- 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 whendefault_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
anddelete_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
v1.5.9
Fix runit RPM file location for Chef provisionless Centos 5.9 Box Image
v1.5.8
Fixing string interpolation bug
v1.5.3
Fixing assignment/compare error
v1.5.1
Bug
- COOK-3950 - runit cookbook should use full service path when checking running status
v1.5.0
Improvement
- **[COOK-3267] - Improve testing suite in runit cookbook
- Updating test-kitchen harness
- Cleaning up style for rubocop
v1.4.4
fixing metadata version error. locking to < 3.0
v1.4.2
Locking yum dependency to '< 3'
v1.4.0
[COOK-3560] Allow the user to configure runit's timeout (-w) and verbose (-v) settings
v1.3.0
Improvement
- COOK-3663 - Add ./check scripts support
Bug
- COOK-3271 - Fix an issue where runit fails to install rpm package on rehl systems
v1.2.0
New Feature
- COOK-3243 - Expose LSB init directory as a configurable
Bug
- COOK-3182 - Do not hardcode rpmbuild location
Improvement
- COOK-3175 - Add svlogd config file support
- COOK-3115 - Add ability to install 'runit' package from Yum
v1.1.6
Bug
- [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
v1.1.4
Bug
- [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
v1.1.2
- [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
v1.1.0
- [COOK-2353] - Runit does not update run template if the service is already enabled
- [COOK-2497] - add :nothing to allowed actions
v1.0.6
- [COOK-2404] - allow sending sigquit
- [COOK-2431] - gentoo - it should create the runit-start template before calling it
v1.0.4
- [COOK-2351] - add
run_template_name
to allow alternate run script template
v1.0.2
- [COOK-2299] - runit_service resource does not properly start a non-running service
v1.0.0
- [COOK-2254] - (formerly CHEF-154) Convert
runit_service
definition to a service resource namedrunit_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 environment(s).
Changes of note
- The "runit" recipe must be included before the runit_service resource can be used.
- The
runit_service
definition created a separateservice
resource for notification purposes. This is still available, but the only actions that can be notified are:start
,:stop
, and:restart
. - The
:enable
action blocks waiting for supervise/ok after the service symlink is created. - User-controlled services should be created per the runit documentation; see README.md for an example.
- 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)
v0.16.2
- [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
v0.16.0
- [COOK-794] default logger and
no_log
forrunit_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
v0.15.0
- [COOK-1008] - Added parameters for names of different templates in runit
Collaborator Number Metric
5.1.3 passed this metric
Contributing File Metric
5.1.3 passed this metric
Foodcritic Metric
5.1.3 passed this metric
No Binaries Metric
5.1.3 passed this metric
Testing File Metric
5.1.3 passed this metric
Version Tag Metric
5.1.3 passed this metric
5.1.3 passed this metric
5.1.3 passed this metric
Foodcritic Metric
5.1.3 passed this metric
No Binaries Metric
5.1.3 passed this metric
Testing File Metric
5.1.3 passed this metric
Version Tag Metric
5.1.3 passed this metric
5.1.3 passed this metric
5.1.3 passed this metric
Testing File Metric
5.1.3 passed this metric
Version Tag Metric
5.1.3 passed this metric
5.1.3 passed this metric
5.1.3 passed this metric