chef-cookbooks / runit Goto Github PK
View Code? Open in Web Editor NEWDevelopment repository for the Chef Runit Cookbook
Home Page: https://supermarket.chef.io/cookbooks/runit
License: Apache License 2.0
Development repository for the Chef Runit Cookbook
Home Page: https://supermarket.chef.io/cookbooks/runit
License: Apache License 2.0
Currently using mini-test Chef Handler to run tests. We should use Serverspec and Chefspec for tests.
@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
.
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
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
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
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
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.
When enabling a previously disabled runit service, the converge will fail (although the service will actually start). The steps to reproduce:
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.
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.
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.
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!
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.
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.
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.
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?
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.
resource = chef_run.runit_service('myservice')
Missing chef_run matcher?
# matchers.rb
ChefSpec.define_matcher :runit_service
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>'
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.
Stuck with rabbitmq failing....
Before I get into the details, a couple of things I needed to do on a fresh Centos 7 install:
* 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
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)
* 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....
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
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.
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.
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.
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?
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.
I have a problem when our cookbook sends a restart to the runit_service. I get:
NoMethodError: No resource or method named action_restart' for
Chef::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?
because options attribute getter/setter will try merge in env_dir, it tries to call merge! on DelayedEvaluator object.
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.
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?
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/
I will make a PR that fixes this issue.
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
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
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.
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.
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
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 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.
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.
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
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 ~]#
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}
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
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
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>
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```
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.
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.
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.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.