chef-cookbooks / runit

Development repository for the Chef Runit Cookbook

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:

• http://smarden.org/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'] - 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.

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 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.

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 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 - 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'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_flags - The flags to pass to the svlogd command. Used when default_logger is true. 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 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.

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 [email protected]
• Author:: Joshua Timberman [email protected]
• Author:: Sean OMeara [email protected]

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's Issues

glibc-static dependency on RHEL

Looks like it is hard to find a blessed version of glibc-static rpm. Wondering if there is a way around this dependency.
I am having a lot of trouble installing this cookbook due to this issue.

Appreciate any help.

• Shekar

log_size not honored when using default_logger

If both of these are set:
default_logger true
log_size 50000000

The log_size property is not honored.

I think this is because the log config file is being placed in:
/etc/sv/#{service-name}/log

Instead of /var/log/#{service-name}

Create action with restart_on_update starts service early

I have a few instances of a pattern where I create a runit_service with action :create, but don't start and enable it until the after some other action like a deploy, or at the end of the run with a delayed notification. I don't think this is possible after the restart_on_update changes in #170.

Delayed notifications for inline resources are run at the end of the provider action, not the end of the Chef run: docs in provider.rb -- So the new ruby blocks always start and enable the service immediately after creating it if restart_on_update is true.

I don't really know of a good a way around that, and maybe it's intended, but at the very least should probably be noted in the docs.

not working with oracle linux : 404 not found

runit is not working with oracle linux. I tested with oracle linux 6.6. and I got error in below.

ERROR: packagecloud_repo[imeyer/runit/](runit::default line 42) had an error: RuntimeError: #<Net::HTTPNotFound 404 Not Found readbody=true>

runit 2.1.2

Via the supervision mailing list, Gerrit Pape has updated runit to version 2.1.2.

version 2.1.2 of the runit package is available for through

 http://smarden.org/runit/

The sv program learns the LSB init script actions reload and
try-restart.  It also fixes two bugs that lead to wrong or badly
formatted output under some circumstances when reporting status of
services, and its documentation now properly states that on exit no
TERM signal is sent to the optional log service, but its standard
input is closed.

What this means for the cookbook is that the runit-2.1.1.tar.gz packaging needs to be updated.

packagecloud.io packages

Ian Meyer has published RPMs of runit on packagecloud.io. We should use those for installing runit packages on EL-family distros, instead of using the runit tarball in the files directory, as Ian is the creator of the RPM data files we use in the cookbook.

restart_on_update doesn't seem to work

I'm using the default value of restart_on_update (true) and my services aren't restarted when the run script changes. I think this started when I upgraded to the new resource-based model.

Release develop contents

Develop has a fix for running this cookbook under Docker that allows us to test cookbooks that use runit with kitchen-dokken. It would be really helpful to get that pushed up to Supermarket so we can start testing community cookbooks in Travis

runit_service enable failing in docker

When I run inside docker container attempt to do

runit_service "myservice" do
  # ...
  action :enable
end

goes to infinitive loop. Because of the following code

service_link.run_action(:create)
Chef::Log.debug("waiting until named pipe #{service_dir_name}/supervise/ok exists.")
until ::FileTest.pipe?("#{service_dir_name}/supervise/ok")
  sleep 1
  Chef::Log.debug('.')
end

This code cannot succeed inside docker container because docker container as will be executed during "build docker image" stage

Runit issues with runit_service[zookeeper]

Hello,
I am having trouble getting runit service start zookeeper.

I get this error:
Error executing action enable on resource 'runit_service[zookeeper]'
Could not locate main runit sv_bin at "/sbin/sv". Did you remember to install runit before declaring a "runit_service" resource?

cookbooks/zookeeper/recipes/service.rb has:
49: runit_service 'zookeeper' do
50: default_logger true
51: options({
52: exec: executable_path
53: })
54: action [:enable, :start]
55: end
56: when 'exhibitor'

I see that runit is getting installed earlier. I also tried to including runit in the recipe cookbooks/zookeeper/recipes/service.rb

include_recipe "runit"

Appreciate any guidance.

• Shekar

Intermittent 'unable to open supervise/ok: file does not exist' errors

I was using runit 1.7.2 and recently started getting unable to open supervise/ok: file does not exist errors when the chef-client run got to a step in the logstash cookbook which tried to restart a logstash service configured to use runit. Not sure if these errors started appearing when chef client got updated to 12.4.

I'm now pinned at 1.5.18 and haven't seen the error anymore.

Running on Centos 6.6

runit_service doesn't respect custom sv_bin on Debian

On Debian the init.d file created by runit_service hardcodes the sv_bin to /usr/bin/sv.
This breakes runit when there is no sv in /usr/bin.
The scriptname is also hardcoded to /etc/init.d/

See https://github.com/hw-cookbooks/runit/blob/53049a01ca40c166ba54cd19f643f086975fe207/templates/debian/init.d.erb#L16-17

I will make a PR that fixes this issue.

Allow ignoring of notifications when setting start_down to true

Greetings,

I'd like to short-circuit the restart action in the event start_down is set to true (which creates the down file telling runit to not automatically start the service). This would effectively make notifications like restart or hup become a no-op in Chef if the service is currently down or marked down. Might attempt a PR for this in the future, but also not sure if people want something like this.

Allow use in Docker

It would be nice if there was a resource-level override for "yes I know I'm inside Docker but I promise everything will be okay". My current hack is more fragile than I would like.

runit_service :enable not idempotent.

Is it possible to ensure that runit runs idempotently?

i.e. if I have fully deployed a server and there are no changes made to the cookbook, 'knife node lastrun' should not show runit_services being enabled on each and every run?

How to use owner and group attribute?

I setup runit service for vagrant.
I add config node attribute

"runit": {
      "owner": "vagrant",
      "group": "vagrant"
 }

But it not work. I ssh to vagrant and run

sv status nginx

I got an message unable to open supervise/ok: access denied

runit_service reports two resources in ChefSpec coverage

The runit_service creates two resources that ChefSpec shows in the coverage report. This results in less than 100% code coverage, which makes me sad. To recreate this:

Recipe:

include_recipe 'runit'
runit_service 'test'

Spec:

require 'chefspec'

describe 'test' do
  include_context('chef recipe run', 'test')

  it 'does not have 100% code coverage' do
    expect(chef_run).to enable_runit_service('test')
  end
end

Running the tests:

$ rspec
test
  does not have 100% code coverage

Finished in 0.11123 seconds
1 example, 0 failures

ChefSpec Coverage report generated...

  Total Resources:   2
  Touched Resources: 1
  Touch Coverage:    50.0%

Untouched Resources:

  service[test]                      Unknown:Unknown

Currently you can get around this by adding a line to the spec like this:

Spec:

require 'chefspec'

describe 'test' do
  include_context('chef recipe run', 'test')

  it 'has 100% code coverage' do
    expect(chef_run).to enable_runit_service('test')
    expect(chef_run.service('test')).to do_nothing # Hack for ChefSpec coverage
  end
end

Which then results in 100% coverage:

$ rspec

test
  has 100% code coverage

Finished in 0.11324 seconds
2 examples, 0 failures

ChefSpec Coverage report generated...

  Total Resources:   2
  Touched Resources: 2
  Touch Coverage:    100.0%

You are awesome and so is your test coverage! Have a fantastic day!

Any idea why this is or how it might be fixed?

on rhel7 or centos7 it doen't work

it doesn't create any vaild service..
is there any plan for rhel7 or centos7?

recipe: push-jobs::service_runit
  * runit_service[opscode-push-jobs-client] action start

    ================================================================================
    Error executing action `start` on resource 'runit_service[opscode-push-jobs-client]'
    ================================================================================

    Mixlib::ShellOut::ShellCommandFailed
    ------------------------------------
    Expected process to exit with [0], but received '1'
    ---- Begin output of /sbin/sv start /etc/service/opscode-push-jobs-client ----
    STDOUT: warning: /etc/service/opscode-push-jobs-client: unable to open supervise/ok: file does not exist
    STDERR: 
    ---- End output of /sbin/sv start /etc/service/opscode-push-jobs-client ----
    Ran /sbin/sv start /etc/service/opscode-push-jobs-client returned 1

    Cookbook Trace:
    ---------------
    /var/chef/cache/cookbooks/runit/libraries/provider_runit_service.rb:176:in `start_service'

    Resource Declaration:
    ---------------------
    # In /var/chef/cache/cookbooks/push-jobs/recipes/service_runit.rb

     23: runit_service 'opscode-push-jobs-client' do
     24:   default_logger true
     25:   subscribes :restart, "template[#{PushJobsHelper.config_path}]"
     26:   action [ :enable, :start ]
     27:   retries 15
     28: end

    Compiled Resource:
    ------------------
    # Declared in /var/chef/cache/cookbooks/push-jobs/recipes/service_runit.rb:23:in `from_file'

    runit_service("opscode-push-jobs-client") do
      provider Chef::Provider::Service::Runit
      action [:enable, :start]
      updated true
      supports {:restart=>true, :reload=>true, :status=>true}
      retries 15
      retry_delay 2
      default_guard_interpreter :default
      service_name "opscode-push-jobs-client"
      enabled true
      pattern "opscode-push-jobs-client"
      status_command "/sbin/sv status /etc/service"
      sv_bin "/sbin/sv"
      sv_dir "/etc/sv"
      service_dir "/etc/service"
      lsb_init_dir "/etc/init.d"
      log true
      default_logger true
      restart_on_update true
      run_template_name "opscode-push-jobs-client"
      log_template_name "opscode-push-jobs-client"
      check_script_template_name "opscode-push-jobs-client"
      finish_script_template_name "opscode-push-jobs-client"
      sv_templates true
      service_mirror # Declared in 

    service("opscode-push-jobs-client") do
      provider Chef::Provider::Service::Simple
      action [:nothing]
      supports {:restart=>true, :reload=>true, :status=>true}
      retries 0
      retry_delay 2
      default_guard_interpreter :default
      service_name "opscode-push-jobs-client"
      pattern "opscode-push-jobs-client"
      start_command "/sbin/sv start /etc/service/opscode-push-jobs-client"
      stop_command "/sbin/sv stop /etc/service/opscode-push-jobs-client"
      status_command "/sbin/sv status /etc/service/opscode-push-jobs-client"
      restart_command "/sbin/sv restart /etc/service/opscode-push-jobs-client"
    end

      declared_type :runit_service
      cookbook_name "push-jobs"
      recipe_name "service_runit"
    end


Running handlers:
[2015-04-24T22:37:45+09:00] ERROR: Running exception handlers
Running handlers complete
[2015-04-24T22:37:45+09:00] ERROR: Exception handlers complete
[2015-04-24T22:37:45+09:00] FATAL: Stacktrace dumped to /var/chef/cache/chef-stacktrace.out
Chef Client failed. 2 resources updated in 94.366871368 seconds
[2015-04-24T22:37:45+09:00] ERROR: runit_service[opscode-push-jobs-client] (push-jobs::service_runit line 23) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '1'
---- Begin output of /sbin/sv start /etc/service/opscode-push-jobs-client ----
STDOUT: warning: /etc/service/opscode-push-jobs-client: unable to open supervise/ok: file does not exist
STDERR: 
---- End output of /sbin/sv start /etc/service/opscode-push-jobs-client ----
Ran /sbin/sv start /etc/service/opscode-push-jobs-client returned 1

Semver, 1.7.0, and ENV files

I'll start by saying thank you for the many Heavy Water cookbooks I've used over the years. I've saved a ton of time over my career using your work. I'm not angry or unappreciative, but more concerned for the safety of others. It's open source and as such the burden of testing and maintenance is on me and I probably should have read through all the specific changes before I the 1.7.0 release out.

That being said the 1.7.0 release killed my environment and will probably continue to do so for others. The refactor to a LWRP from a collection of libraries was a monumental change that was done at the same time that behavior changed. Those changes would be fine if A) it was spelled out in the changelog how large of a change this was and B) the cookbook was rev'd to 2.0. A huge portion of the Chef community depends on this cookbook and most people seem to set their deps to 1.X.

In the refactor to a LWRP a new bit of functionality was added that deleted runit ENV files not managed by the LWRP (https://github.com/hw-cookbooks/runit/blob/develop/libraries/provider_runit_service.rb#L153). This was an entirely new feature, which could not be turned off and wasn't mentioned in the changelog. The deletion also occurred via a Ruby block so no backups of the files were taken before they were deleted. I rolled the 1.7 release out to a good number of systems that did not include additional ENV files and found no issues with the changes. As I pushed the changes to my DJBDNS hosts all ENV files for DJBDNS were deleted which completely deleted the config for the service. Afterwards the services were restarted and all of my internal DNS and external name resolution stopped. At that point access to my systems became fairly difficult (LDAP w/o DNS == no fun), and the customer facing portion of the application failed as name resolution to key resources the application used failed. I managed to roll back the dep to the 1.6.0 release, but since the files weren't actually managed by Chef this didn't do anything. After determining which files were there and what they included I managed to recreate the proper ENV files and return DNS resolution to normal, but not before a pretty painful outage.

There were certainly some important life lessons here such as not trusting why-run and not assuming execution on one type of system equals safety on all. I still can't help but think that this whole thing could be avoided with a semver bump and a more verbose changelog. 1.7.0 is a fairly new release and a lot of people are going to run into this same issue as the new release gets pulled in for other cookbooks. The env pruning functionality needs to get removed. If it comes back it needs to be the non-default functionality of the LWRP. Until then the 1.7.0 release needs to get pulled to prevent blowing away further setups.

No resource or method named `action_start'

Hello,

Going between 1.6.0 and 1.7.0 is giving me an error. I can't seem to find a change that would cause this in the commits. The error is:

 NoMethodError
           -------------
           No resource or method named `action_start' for `Chef::Provider::RunitService ""'

my runit_service resource is configured:

runit_service 'statsd' do
  action [:enable, :start]
  default_logger true
  options ({
    :user => node['statsd']['username'],
    :statsd_dir => node['statsd']['dir'],
    :conf_dir => node['statsd']['conf_dir'],
    :nodejs_bin => node['nodejs']['path']
  })

It looks like it's not liking the start action, but I can't figure out why. It works fine with 1.6.

Any help is appreciated, thanks!

CONTRIBUTING.md documentation is out of date

The contribution readme documentation appears to be out of date. It links to the Chef JIRA (which has been deprecated for some time now). Also, are the CLA for opscodes truly a requirement for contributing to hw-cookbooks? It appears as though the contributing.md file was reused from an official chef codebase. Other hw-cookbooks (like graphite) have a completely different contributing readme.

sv_timeout default attribute is not working

When I use the runit cookbook to restart the service it fails. I identified that service takes some more time to stop and thereby sv restarts fails after 7seconds of timeout. I wanted to override this timeout by overriding the default attribute sv_timeout, but no luck. I still see the sv command failing to restart

           ================================================================================

   Mixlib::ShellOut::ShellCommandFailed
   ------------------------------------
   Expected process to exit with [0], but received '1'
   ---- Begin output of /sbin/sv restart /etc/service/runscope_radar_agent ----
   STDOUT: timeout: run: /etc/service/runscope_radar_agent: (pid 20214) 331s, got TERM
   STDERR:
   ---- End output of /sbin/sv restart /etc/service/runscope_radar_agent ----
   Ran /sbin/sv restart /etc/service/runscope_radar_agent returned 1```

Create service but do not start it?

Is it possible to create a new service but not attempt to start it? I'm creating services that will only be brought up in certain circumstances.

I think what I'm after is an action :configure option.

Cheers.

waiting until named pipe shall have a timeout

For some reason sometimes a service is suppose to have a named piped created but it does not work.

exemple:
waiting until named pipe /etc/service/nginx/supervise/ok exists.

This should fail after a certain amount of time as now it hangs forever.

Enabling a previously disabled runit service will fail to converge

When enabling a previously disabled runit service, the converge will fail (although the service will actually start). The steps to reproduce:

1. Create a new runit service, and enable it.
2. In another converge, disable the previous runit service
3. In another converge, enable the previous runit service

Because of step 1, the service's supervise/ok named pipe exists at step 3, and so the runit cookbook falsely detects the service as already being ready to use. The supervise/ok named pipe should be deleted in step 2 to prevent this from occurring.

runit_service not restarted on env change

When the env values passed to an runit_service resource change, the service should be restarted to ensure that it picks up on the intended changes to its environment. However, it appears that the environment values are not checked when determining whether or not the service should be restarted.

An additional check, such as the following, would probably suffice:

restart_service if @new_resource.restart_on_update && env_files.any? { |file| file.updated_by_last_action? }

It's time to remove support for Ubuntu 8.04

There's a ton of cruft in the default recipe that relates to LONG ago deprecated releases of Debian and Ubuntu. Things could be greatly simplified by removing a lot of this logic. If anyone out there is still relying on Chef to run their Ubuntu 8.04 infrastructure I highly doubt they're pulling in the latest and greatest runit cookbook so this has a 0 chance of hurting anyone.

Support systemd as the underlying init system

We need to start runsvdir under systemd like we do for sysv and upstart. It's probably worth separating each underlying init system out to its own recipe, and use the ohai-detected automatic attribute init_package to select the right thing.

TERM signal not working

So I am trying to send Sidekiq a TERM signal using runit at the end of a deploy. At the beginning of the deploy, I send it a USR1 which works fine which is confirmed by the process showing "stopping". With the TERM signal, however, nothing happens.

Recipe:

action :before_migrate do
  runit_service 'sidekiq' do
    action :usr1 # WORKS
  end
end

action :after_restart do
  runit_service 'sidekiq' do
    action :term # DOESN'T WORK
  end
end

Chef shows:

runit_service[sidekiq] action term
    - send term to runit_service[sidekiq]

but the process still shows "stopping" as if no further signal was received after USR1.

If I manually send sudo sv TERM sidekiq I get:

kill: run: sidekiq: (pid 7263) 3176s, got TERM

and the process restarts. The runit_service resource only accepts action :term, not action :TERM so I'm not sure if the conversion of the parameter action to the actual signal is the issue

I have also just tried referencing the init.d symlink:

execute '/etc/init.d/sidekiq TERM' do
  user 'root'
end

but it seems to result in a non-zero exit code:

Mixlib::ShellOut::ShellCommandFailed
  ------------------------------------
  execute[/etc/init.d/sidekiq TERM] (/var/chef/cache/cookbooks/application_ruby/providers/sidekiq.rb line 74) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '1'
  ---- Begin output of /etc/init.d/sidekiq TERM ----
  STDOUT: kill: run: sidekiq: (pid 19404) 734s, got TERM
  STDERR:
  ---- End output of /etc/init.d/sidekiq TERM ----
  Ran /etc/init.d/sidekiq TERM returned 1

I found an answer stating that for Capistrano deploys they would stop the sidekiq runit service, manually stop sidekiq and then start the runit sidekiq service, but that seems super hacky 😬

http://stackoverflow.com/questions/22060610/sidekiq-fails-to-stop-under-runit/22077734#22077734

Any idea why the term signal doesn't work?

Waiting for service sockets broken

This was broken during the big refactor https://github.com/hw-cookbooks/runit/blob/develop/libraries/provider_runit_service.rb#L246-L249

Previously the runit_service provider code correctly waited for runsv to actually recognize the new service. This was removed and I don't see that the functionality was added elsewhere.

runsvdir-start doesn't start inside docker without init

In docker container runsvdir-start doesn't start (at least for debian).

The root cause of issue is init system inside container.

Package runit relays on /etc/inittab with:

#-- runit begin
SV:123456:respawn:/usr/sbin/runsvdir-start
#-- runit end

Then it send HUP signal to process with pid 1.
Under test-kitchen pid 1 is sshd. So there are no way to start runit using only package.

Most service actions no longer idempotent

The LWRP rewrite removed the Chef::Provider::Service base class, and in doing so removed a lot of the idempotence checks on things like start and stop commands. Either these checks should be re-added to the runit service provider or the service base class should be used again.

Ping @someara.

release 1.5.11?

Hi,

since March there hasn't been a release.

I know there's the chefspec matcher.rb that's been added since and I'd love to use this outside of a development version of the runit cookbook.

How about releasing this as it is?

Cheers,
Markus

Chef 12.6.0 - property group is declared in both directory[/etc/sv/chef-client/log] and #<Chef::Provider::RunitService:0x0000000da390a0>. Use new_resource.group instead.

Seeing this warn in chef 12.6.0 and runit cookbook version > 1.7.4

 * runit_service[chef-client] action enable[2015-12-30T21:11:49+00:00] WARN: /var/chef/cache/cookbooks/runit/libraries/provider_runit_service.rb:58:in `block (2 levels) in <class:RunitService>': property group is declared in both directo
ry[/etc/sv/chef-client] and #<Chef::Provider::RunitService:0x0000000da390a0>. Use new_resource.group instead. At /var/chef/cache/cookbooks/runit/libraries/provider_runit_service.rb:58:in `block (2 levels) in <class:RunitService>'
[2015-12-30T21:11:49+00:00] WARN: /var/chef/cache/cookbooks/runit/libraries/provider_runit_service.rb:66:in `block (2 levels) in <class:RunitService>': property group is declared in both template[/etc/sv/chef-client/run] and #<Chef::Provi
der::RunitService:0x0000000da390a0>. Use new_resource.group instead. At /var/chef/cache/cookbooks/runit/libraries/provider_runit_service.rb:66:in `block (2 levels) in <class:RunitService>'
[2015-12-30T21:11:49+00:00] WARN: /var/chef/cache/cookbooks/runit/libraries/provider_runit_service.rb:78:in `block (2 levels) in <class:RunitService>': property group is declared in both directory[/etc/sv/chef-client/log] and #<Chef::Prov
ider::RunitService:0x0000000da390a0>. Use new_resource.group instead. At /var/chef/cache/cookbooks/runit/libraries/provider_runit_service.rb:78:in `block (2 levels) in <class:RunitService>'
[2015-12-30T21:11:49+00:00] WARN: /var/chef/cache/cookbooks/runit/libraries/provider_runit_service.rb:85:in `block (2 levels) in <class:RunitService>': property group is declared in both directory[/etc/sv/chef-client/log/main] and #<Chef:
:Provider::RunitService:0x0000000da390a0>. Use new_resource.group instead. At /var/chef/cache/cookbooks/runit/libraries/provider_runit_service.rb:85:in `block (2 levels) in <class:RunitService>'
[2015-12-30T21:11:49+00:00] WARN: /var/chef/cache/cookbooks/runit/libraries/provider_runit_service.rb:93:in `block (2 levels) in <class:RunitService>': property group is declared in both directory[/var/log/chef-client] and #<Chef::Provide
r::RunitService:0x0000000da390a0>. Use new_resource.group instead. At /var/chef/cache/cookbooks/runit/libraries/provider_runit_service.rb:93:in `block (2 levels) in <class:RunitService>'
[2015-12-30T21:11:49+00:00] WARN: /var/chef/cache/cookbooks/runit/libraries/provider_runit_service.rb:101:in `block (2 levels) in <class:RunitService>': property group is declared in both template[/etc/sv/chef-client/log/config] and #<Che
f::Provider::RunitService:0x0000000da390a0>. Use new_resource.group instead. At /var/chef/cache/cookbooks/runit/libraries/provider_runit_service.rb:101:in `block (2 levels) in <class:RunitService>'
[2015-12-30T21:11:49+00:00] WARN: /var/chef/cache/cookbooks/runit/libraries/provider_runit_service.rb:124:in `block (2 levels) in <class:RunitService>': property group is declared in both template[/etc/sv/chef-client/log/run] and #<Chef::
Provider::RunitService:0x0000000da390a0>. Use new_resource.group instead. At /var/chef/cache/cookbooks/runit/libraries/provider_runit_service.rb:124:in `block (2 levels) in <class:RunitService>'
[2015-12-30T21:11:49+00:00] WARN: /var/chef/cache/cookbooks/runit/libraries/provider_runit_service.rb:138:in `block (2 levels) in <class:RunitService>': property group is declared in both directory[/etc/sv/chef-client/env] and #<Chef::Pro
vider::RunitService:0x0000000da390a0>. Use new_resource.group instead. At /var/chef/cache/cookbooks/runit/libraries/provider_runit_service.rb:138:in `block (2 levels) in <class:RunitService>'
[2015-12-30T21:11:49+00:00] WARN: /var/chef/cache/cookbooks/runit/libraries/provider_runit_service.rb:186:in `block (2 levels) in <class:RunitService>': property group is declared in both directory[/etc/sv/chef-client/control] and #<Chef:
:Provider::RunitService:0x0000000da390a0>. Use new_resource.group instead. At /var/chef/cache/cookbooks/runit/libraries/provider_runit_service.rb:186:in `block (2 levels) in <class:RunitService>'

Failures on RHEL 7

Stuck with rabbitmq failing....

Before I get into the details, a couple of things I needed to do on a fresh Centos 7 install:

1. I had only done a base install, but "private-chef-ctl reconfigure" failed until I installed httpd, then ran a system update and rebooted.
2. I was then getting a hanging behavior here:

* link[/opt/opscode/init/couchdb] action create
    - create symlink at /opt/opscode/init/couchdb to /opt/opscode/embedded/bin/sv
    - configure service runit_service[couchdb]
* link[/opt/opscode/service/couchdb] action create
    - create symlink at /opt/opscode/service/couchdb to /opt/opscode/sv/couchdb

1. After some digging, it became apparent that I was missing the "erlang" package, which was not available at the CentOS 7 repository. I added the EPEL 7 repo file, then installed "erlang".... that seemed to get me past this portion.
2. Now I'm stuck here:

Recipe: private-chef::rabbitmq
  * runit_service[rabbitmq] action enableRecipe: <Dynamically Defined Resource>
  * directory[/opt/opscode/sv/rabbitmq] action create (up to date)
  * template[/opt/opscode/sv/rabbitmq/run] action create (up to date)
  * directory[/opt/opscode/sv/rabbitmq/log] action create (up to date)
  * directory[/opt/opscode/sv/rabbitmq/log/main] action create (up to date)
  * template[/opt/opscode/sv/rabbitmq/log/run] action create (up to date)
  * template[/opt/opscode/sv/rabbitmq/log/config] action create (up to date)
  * link[/opt/opscode/init/rabbitmq] action create (up to date)

    - configure service runit_service[rabbitmq]

Recipe: private-chef::rabbitmq
  * execute[/opt/opscode/bin/private-chef-ctl start rabbitmq] action run
================================================================================
Error executing action `run` on resource 'execute[/opt/opscode/bin/private-chef-ctl start rabbitmq]'
================================================================================


Mixlib::ShellOut::ShellCommandFailed
------------------------------------
Expected process to exit with [0], but received '1'
---- Begin output of /opt/opscode/bin/private-chef-ctl start rabbitmq ----
STDOUT: warning: rabbitmq: unable to open supervise/ok: file does not exist
STDERR:
---- End output of /opt/opscode/bin/private-chef-ctl start rabbitmq ----
Ran /opt/opscode/bin/private-chef-ctl start rabbitmq returned 1


Resource Declaration:
---------------------
# In /opt/opscode/embedded/cookbooks/private-chef/recipes/rabbitmq.rb

 79:   execute "#{opc_ctl} start rabbitmq" do
 80:     retries 20
 81:   end
 82:



Compiled Resource:
------------------
# Declared in /opt/opscode/embedded/cookbooks/private-chef/recipes/rabbitmq.rb:79:in `from_file'

execute("/opt/opscode/bin/private-chef-ctl start rabbitmq") do
  action "run"
  retries 0
  retry_delay 2
  command "/opt/opscode/bin/private-chef-ctl start rabbitmq"
  backup 5
  returns 0
  cookbook_name :"private-chef"
  recipe_name "rabbitmq"
end

Running handlers:
[2014-11-21T12:15:45-05:00] ERROR: Running exception handlers
Running handlers complete

[2014-11-21T12:15:45-05:00] ERROR: Exception handlers complete
[2014-11-21T12:15:45-05:00] FATAL: Stacktrace dumped to /opt/opscode/embedded/cookbooks/cache/chef-stacktrace.out
Chef Client failed. 2 resources updated in 51.528969427 seconds
[2014-11-21T12:15:45-05:00] ERROR: execute[/opt/opscode/bin/private-chef-ctl start rabbitmq] (private-chef::rabbitmq line 79) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '1'
---- Begin output of /opt/opscode/bin/private-chef-ctl start rabbitmq ----
STDOUT: warning: rabbitmq: unable to open supervise/ok: file does not exist
STDERR:
---- End output of /opt/opscode/bin/private-chef-ctl start rabbitmq ----
Ran /opt/opscode/bin/private-chef-ctl start rabbitmq returned 1
[2014-11-21T12:15:45-05:00] FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1)

1. I installed "librabbitmq", "librabbitmq-devel", and "rabbitmq-server", rebooted, then reinstalled "private-chef (11.1.6). Ditched this version and downloaded 12, since I am getting to the same place.
2. Version 12 is the same.... hangs here:

* directory[/opt/opscode/sv/rabbitmq/log/main] action create
    - create new directory /opt/opscode/sv/rabbitmq/log/main
    - change mode from '' to '0755'

  * template[/opt/opscode/sv/rabbitmq/log/run] action create
    - create new file /opt/opscode/sv/rabbitmq/log/run
    - update content in file /opt/opscode/sv/rabbitmq/log/run from none to 0e09b8
        --- /opt/opscode/sv/rabbitmq/log/run    2014-11-21 13:07:03.303442999 -0500
        +++ /tmp/chef-rendered-template20141121-1933-1l5gq9c    2014-11-21 13:07:03.305442999 -0500
        @@ -1 +1,4 @@
        +#!/bin/sh
        +exec chpst -U opscode -u opscode \
        +  svlogd -tt /var/log/opscode/rabbitmq
    - change mode from '' to '0755'

  * template[/opt/opscode/sv/rabbitmq/log/config] action create
    - create new file /opt/opscode/sv/rabbitmq/log/config
    - update content in file /opt/opscode/sv/rabbitmq/log/config from none to e3b0c4
        (no diff)
    - change mode from '' to '0644'

  * link[/opt/opscode/init/rabbitmq] action create
    - create symlink at /opt/opscode/init/rabbitmq to /opt/opscode/embedded/bin/sv


    - configure service runit_service[rabbitmq]  * link[/opt/opscode/service/rabbitmq] action create
    - create symlink at /opt/opscode/service/rabbitmq to /opt/opscode/sv/rabbitmq

Just hangs right here....

rhel_build_install access the internet

    bash 'rhel_build_install' do
      user 'root'
      cwd Chef::Config[:file_cache_path]
      code <<-EOH
        tar xzf runit-2.1.1.tar.gz
        cd runit-2.1.1
        ./build.sh
        rpm_root_dir=`rpm --eval '%{_rpmdir}'`
        rpm -ivh "${rpm_root_dir}/runit-2.1.1.rpm"
      EOH
      action :run
      not_if rpm_installed
    end

while building runit rpm package, it access the internet.
so bash[rhel_build_install] is stalling at isolated intranet.
please let it not to access the internet.

ps:

root      2231  0.1  0.5 217048 42936 pts/2    Sl+  16:10   0:00  |                   \_ /opt/chef/embedded/bin/ruby /usr/bin/chef-client
root      2233  0.7  0.7 239344 56696 pts/2    Sl+  16:10   0:03  |                       \_ chef-client worker: ppid=2231;start=16:10:04;   
root      2450  0.0  0.0   9188  1200 ?        Ss   16:10   0:00  |                           \_ bash /tmp/chef-script20140425-2233-vfi2i1
root      2455  0.0  0.0   9188  1296 ?        S    16:10   0:00  |                               \_ /bin/sh ./build.sh
root      2497  0.0  0.0  35316  5920 ?        S    16:10   0:00  |                                   \_ /usr/bin/perl -w /usr/bin/spectool -C /root/rpmbuild/SOURCES -g ./runit.spec
root      2506  0.0  0.0  41180  2148 ?        S    16:10   0:00  |                                       \_ wget -N --retr-symlinks -P /root/rpmbuild/SOURCES http://smarden.org/runit/runit-2.1.1.tar.gz

netstat:

[root@chef-node ~]# netstat -at | grep smarden
tcp        0      1 chef-node.example.jp:52478  smarden.org:http            SYN_SENT    
[root@chef-node ~]# 

RHEL 5 not supported

It looks like a package is missing in the repo that's needed for RHEL 5

           * packagecloud_repo[imeyer/runit] action add
             * yum_package[pygpgme] action install
        * No candidate version available for pygpgme[2016-02-16T22:02:56+00:00] ERROR: yum_package[pygpgme] (/tmp/kitchen/cache/cookbooks/packagecloud/providers/repo.rb line 73) had an error: Chef::Exceptions::Package: No candidate version available for pygpgme; ignore_failure is set, continuing

        ================================================================================
        Error executing action `install` on resource 'yum_package[pygpgme]'
        ================================================================================

        Chef::Exceptions::Package
        -------------------------
        No candidate version available for pygpgme

        Cookbook Trace:
        ---------------
        /tmp/kitchen/cache/cookbooks/compat_resource/files/lib/chef_compat/copied_from_chef/chef/provider.rb:119:in `compile_and_converge_action'

        Resource Declaration:
        ---------------------
        # In /tmp/kitchen/cache/cookbooks/packagecloud/providers/repo.rb

         73:   package 'pygpgme' do
         74:     ignore_failure true
         75:   end
         76:

        Compiled Resource:
        ------------------
        # Declared in /tmp/kitchen/cache/cookbooks/packagecloud/providers/repo.rb:73:in `install_rpm'

        yum_package("pygpgme") do
          package_name "pygpgme"
          action [:install]
          ignore_failure true
          retries 0
          retry_delay 2
          default_guard_interpreter :default
          declared_type :package
          cookbook_name "runit"
          flush_cache {:before=>false, :after=>false}
        end

Why for debian runit uses separate template?

It is not clear for me why debian/init.d.erb exists?
I testes symlinking on debian:

ln -s /usr/bin/sv /etc/init.d/my-service

And it seems to work.
If there is a reason for this, then we missing some actions, like force-stop and kill.

svlogd configuration in wrong place?

When I use the runit_service in my cookbook like this:

runit_service "nutcracker" do
  action [ :enable, :start ]
  run_template_name 'nutcracker'
  default_logger    true
  log_size           50000000
  cookbook          'nutcracker'
end

It creates the svlogd configuration under /etc/sv/nutcracker/log/config, but the svlogd reads configuration from /var/log/nutcracker/config (the default dir created by the default_logger true).

The manpage for svlogd says about its configuration file location:

A log directory additionally contains the lock file lock, maybe state and newstate, and optionally the file config. svlogd creates necessary files if they don't exist.

In practice, the config file created by the runit_service resource is useless unless the write directory is the same as the sv control directory (by default /etc/sv/<service>).

Is this the desired behavior? And if it is, what is the best practice to make the config file go to the right place using the runit_service resource instead of putting a template on the write logs directory?

System: Debian GNU/Linux 7.5 (wheezy)
Runit Version: 2.1.1-6.2
Chef Version: 11.12.4-1
Cookbook Version: 1.5.8

log config should be written to log directory regardless of whether or not the default logger is used

@petecheslock indicates that we have shipped a regression with regard to log configs:
https://twitter.com/petecheslock/status/612715767595945984

The changes from #82 seem to have gone missing; I can't tell from commit log when they would have merged to develop. We included #117 in the 1.7.0 release, but that change doesn't resolve the problem for configurations which do not use the default_logger.

rabbitmq: unable to open supervise/ok: file does not exist

Hi

I get below error when i run the "sudo chef-server-ctl reconfigure" on ubuntu running on a docker container. Can you help on this
[2015-09-25T18:30:50+00:00] ERROR: Running exception handlers
Running handlers complete
[2015-09-25T18:30:50+00:00] ERROR: Exception handlers complete
Chef Client failed. 8 resources updated in 136.346012139 seconds
[2015-09-25T18:30:50+00:00] FATAL: Stacktrace dumped to /opt/opscode/embedded/cookbooks/cache/chef-stacktrace.out
[2015-09-25T18:30:50+00:00] FATAL: Mixlib::ShellOut::ShellCommandFailed: execute[/opt/opscode/bin/private-chef-ctl start rabbitmq](private-chef::rabbitmq line 85) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '1'
---- Begin output of /opt/opscode/bin/private-chef-ctl start rabbitmq ----
STDOUT: warning: rabbitmq: unable to open supervise/ok: file does not exist
STDERR:
---- End output of /opt/opscode/bin/private-chef-ctl start rabbitmq ----
Ran /opt/opscode/bin/private-chef-ctl start rabbitmq returned 1

Switch RHEL to use imeyer's packagecloud repo

The build-from-source part of the default recipe for RHEL uses @imeyer's runit-rpm. We should switch to using his Package Cloud repository entirely and remove the "rhel_build_install" resource.

Tighten env_files permissions

In the env_files method the files that get created use the default permissions of 0644.

Environment variables used by a service may contain secrets, so it might be better to create these files with 0600 or 0660 permissions in order to prevent other users on the system from reading sensitive data.

add capability to restart svlog service

It is sometimes desirable to have the log service svlogd be restarted, especially if rendering the log configuration file.

For example, we have a workaround for this in one of our Chef Server cookbooks

Add ability to to flag a runit service as 'down' to prevent runsv from automatically starting it

Some services that can be managed by runit need to be able to be explicitly flagged as 'down' to prevent runsv from starting them automatically. An example of this is runit managed ucarp VIPs. Please support adding /etc/sv/<service>/down files during service configuration.

Log config location wrong for default_logger

It seems that svlogd expects its configuration to be where its log location is. So setting default_logger to true it expects it to be in /var/log/something/config. I just tested it on CentOS 6.6 and setting a symlink works.

if new_resource.default_logger
  directory "/var/log/#{new_resource.service_name}" do
    ...
  end

  link "/var/log/#{new_resource.service_name}/config" do
    to "#{sv_dir_name}/log/config"
  end
...
else

options attribute of runit LWRP will not play along with `lazy`

because options attribute getter/setter will try merge in env_dir, it tries to call merge! on DelayedEvaluator object.

Review and Update Test Coverage

Currently using mini-test Chef Handler to run tests. We should use Serverspec and Chefspec for tests.

Forget for one matcher for chefspec?

resource = chef_run.runit_service('myservice')

Missing chef_run matcher?

# matchers.rb
ChefSpec.define_matcher :runit_service

Restart fails

I have a problem when our cookbook sends a restart to the runit_service. I get:
NoMethodError: No resource or method named action_restart' forChef::Provider::RunitService ""'

Looking through the code I don't see any 'action :restart' in libraries/provider_runit_service.rb
Shouldn't there be one or am I missing something obvious?