kennethkalmer / daemon-kit Goto Github PK

There is an accessor for :pid_file, however the reader is overwritten by a method defined on line 328.

This might not be a problem, but it does look like it gets used in the templates/god/god.erb file

  w.pid_file = "<%= DaemonKit.configuration.pid_file %>"

as well as the templates/monit/monit.erb file:

  :check process <%= DaemonKit.configuration.daemon_name %> with pidfile <%= DaemonKit.configuration.pid_file %>

I'd be happy to fix this, but I'd need a hint as to which direction you'd like to take it in.

In at_exit hooks, you can check $! for SystemExit instances. If you find one, you won't want to call exit, in order to preserve the exit status.

The current repo versions avoidance of calling exit works fine too, though.

Hi, Kennethkalmer

I encounter an error while starting the daemon process, the error code is as follow:

{code}
c:/jruby-1.5.3/lib/ruby/gems/1.8/gems/daemon-kit-0.1.8.1/lib/daemon_kit/applicat
ion.rb:183:in `each_object': ObjectSpace is disabled; each_object will only work
with Class, pass -X+O to enable (RuntimeError)
{code}

by default, the objectspace does not enable in JRuby, so I added "JRuby.objectspace = true" before launching it, I think it's better to add this to README of fix this in the source code.

Because of this:

          self.chroot
          self.redirect_io( true )

byebug or pry are broken.

Is there a workaround to it?

I am looking at your thread pool implementation. I am trying to use ruby 1.9.1 on ubuntu. I see you have comments in there about 1.9 not working on os x. Is it worthwhile trying on ubuntu you think?

Also have you tried in jruby and multithreads? I deployed java on the jvm and it was relatively stable?

Marius

Hi. The example config.multiple option in the environment file is mispelled ("mulitple") but even when corrected I get

undefined method `multiple=' for #<DaemonKit::Configuration:0x1159590> (NoMethodError)

When I try to run the example daemon.

Capistrano script in the rails project that uses daemonkit has following start and stop tasks:

  task :start do
    try_runner "RAILS_ENV=#{fetch(:rails_env)} DAEMON_ENV=#{fetch(:rails_env)} BUNDLE_GEMFILE=#{current_path}/Gemfile bundle exec #{current_path}/bin/#{daemon_name} start"
  end
  task :stop do
    try_runner "cd #{current_path} && RAILS_ENV=#{fetch(:rails_env)} DAEMON_ENV=#{fetch(:rails_env)} bin/#{daemon_name} stop"
  end

Stop task always runs successfully but start task just occasionally would start successfully. Even if it doesn't start, it never reports any problems. ssh debug log also doesn't show any issues.
Any idea about why would this be happening?
Thanks a lot.
Mirela

Due to rabbitmq exchange equivalence (http://lists.rabbitmq.com/pipermail/rabbitmq-announce/2010-June/000025.html) parameters :durable must be set in reply_via_amqp

I found this issue after upgrading my rabbitmq-server to version 2.3

connection <0.18148.5> (running), channel 2 - error:
{amqp_error,precondition_failed,
            "parameters for queue 'done' in vhost 'ping-pong' not equivalent",
            'queue.declare'}

So the channel is closed (inconsistency options)

It is due to MQ.queue in ruote-amqp/receiver.rb:85 that sets durable option.
MQ.queue(@Queue, :durable => true)

But in daemon_kit/ruote_workitem.rb:94

 ::MQ.queue( response['params']['reply_queue'] )

A quick fix is to set option :durable => true

But I don't know if it is a daemon-kit issue or a ruote-amqp issue (But I think I've posted on the write project ... )

The latest version of thor is 0.16.0, whereas version 0.13.6 is vendored in the latest release of daemon-kits.

Is there any reason why thor couldn't be specified as a dependency in the gemspec rather than vendoring the whole library?

(I'd be happy to provide a pull request if this change is desirable)

Hello,

I created a .rake file under tasks/ directory.

namespace :collections do
  desc "Send again collections notifications from specified dates"
  task :resend, [:account, :start_timestamp, :stop_timestamp] => :environment do |t, args|
    puts "#{args}"
  end
end

When I try to launch it:

$ bundle exec rake "collections:resend[unstable,0,0]" --trace
To use rspec for testing you must install rspec gem:
    gem install rspec
** Invoke collections:resend (first_time)
** Invoke environment (first_time)
** Execute environment
rake aborted!
cannot load such file -- config/environment
/Users/julien/.rvm/gems/ruby-1.9.3-p545/gems/daemon-kit-0.1.8.2/lib/daemon_kit/tasks/environment.rake:4:in `require'
/Users/julien/.rvm/gems/ruby-1.9.3-p545/gems/daemon-kit-0.1.8.2/lib/daemon_kit/tasks/environment.rake:4:in `block in <top (required)>'
/Users/julien/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/rake/task.rb:205:in `call'
/Users/julien/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/rake/task.rb:205:in `block in execute'
/Users/julien/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/rake/task.rb:200:in `each'
/Users/julien/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/rake/task.rb:200:in `execute'
/Users/julien/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/rake/task.rb:158:in `block in invoke_with_call_chain'
/Users/julien/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/monitor.rb:211:in `mon_synchronize'
/Users/julien/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/rake/task.rb:151:in `invoke_with_call_chain'
/Users/julien/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/rake/task.rb:176:in `block in invoke_prerequisites'
/Users/julien/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/rake/task.rb:174:in `each'
/Users/julien/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/rake/task.rb:174:in `invoke_prerequisites'
/Users/julien/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/rake/task.rb:157:in `block in invoke_with_call_chain'
/Users/julien/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/monitor.rb:211:in `mon_synchronize'
/Users/julien/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/rake/task.rb:151:in `invoke_with_call_chain'
/Users/julien/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/rake/task.rb:144:in `invoke'
/Users/julien/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/rake/application.rb:116:in `invoke_task'
/Users/julien/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/rake/application.rb:94:in `block (2 levels) in top_level'
/Users/julien/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/rake/application.rb:94:in `each'
/Users/julien/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/rake/application.rb:94:in `block in top_level'
/Users/julien/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/rake/application.rb:133:in `standard_exception_handling'
/Users/julien/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/rake/application.rb:88:in `top_level'
/Users/julien/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/rake/application.rb:66:in `block in run'
/Users/julien/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/rake/application.rb:133:in `standard_exception_handling'
/Users/julien/.rvm/rubies/ruby-1.9.3-p545/lib/ruby/1.9.1/rake/application.rb:63:in `run'
/Users/julien/.rvm/gems/ruby-1.9.3-p545@global/gems/rake-0.9.2.2/bin/rake:32:in `<top (required)>'
/Users/julien/.rvm/gems/ruby-1.9.3-p545/bin/rake:23:in `load'
/Users/julien/.rvm/gems/ruby-1.9.3-p545/bin/rake:23:in `<main>'
/Users/julien/.rvm/gems/ruby-1.9.3-p545/bin/ruby_executable_hooks:15:in `eval'
/Users/julien/.rvm/gems/ruby-1.9.3-p545/bin/ruby_executable_hooks:15:in `<main>'
Tasks: TOP => collections:resend => environment

Ruby's standard Logger class allows you to use blocks for logging messages that may take a non-trivial amount of CPU time to generate:

logger.debug { "This message contains a lot of diagnostic info" }

DK's AbstractLogger just assumes a single string parameter. It should also accept a block.

On CentOS 5.4 with RubyEE 1.8.7, the amqp template generated by daemon-kit 0.1.8rc2 won't start. This also occurs on Mac OS X 10.6.3 with Ruby 1.8.7.

[root@host ~]# daemon-kit amqp -i amqp
<generates daemon>
[root@host ~]# cd amqp
[root@host amqp]# bin/amqp 
/usr/local/lib/ruby/gems/1.8/gems/amqp-0.6.7/lib/mq/exchange.rb:23: uninitialized constant MQ::Exchange::AMQP (NameError)
    from /usr/local/lib/ruby/gems/1.8/gems/amqp-0.6.7/lib/mq.rb:9:in `require'
    from /usr/local/lib/ruby/gems/1.8/gems/amqp-0.6.7/lib/mq.rb:9
    from /usr/local/lib/ruby/gems/1.8/gems/amqp-0.6.7/lib/mq.rb:8:in `each'
    from /usr/local/lib/ruby/gems/1.8/gems/amqp-0.6.7/lib/mq.rb:8
    from /root/src/daemons/amqp/config/pre-daemonize/amqp.rb:3:in `require'
    from /root/src/daemons/amqp/config/pre-daemonize/amqp.rb:3
    from /usr/local/lib/ruby/gems/1.8/gems/daemon-kit-0.1.8rc2/lib/daemon_kit/initializer.rb:155:in `require'
    from /usr/local/lib/ruby/gems/1.8/gems/daemon-kit-0.1.8rc2/lib/daemon_kit/initializer.rb:155:in `load_predaemonize_configs'
    from /usr/local/lib/ruby/gems/1.8/gems/daemon-kit-0.1.8rc2/lib/daemon_kit/initializer.rb:152:in `each'
    from /usr/local/lib/ruby/gems/1.8/gems/daemon-kit-0.1.8rc2/lib/daemon_kit/initializer.rb:152:in `load_predaemonize_configs'
    from /usr/local/lib/ruby/gems/1.8/gems/daemon-kit-0.1.8rc2/lib/daemon_kit/initializer.rb:99:in `before_daemonize'
    from /usr/local/lib/ruby/gems/1.8/gems/daemon-kit-0.1.8rc2/lib/daemon_kit/initializer.rb:58:in `run'
    from ./bin/../config/boot.rb:39:in `run'
    from ./bin/../config/boot.rb:19:in `boot!'
    from ./bin/../config/boot.rb:70
    from ./bin/../config/environment.rb:7:in `require'
    from ./bin/../config/environment.rb:7
    from bin/amqp:6:in `require'
    from bin/amqp:6

We're already depending on Thor for the main daemon generators, it only makes sense to depend on it for ./script/generate and ./script/destroy.

The general rule of thumb is that libraries (like daemon-kit) should not muck about with gems. In this case I'm not using Rubygems at all but bundler so my daemon is completely self-contained aside from ruby and bundler.

** [out :: ec2-174-129-48-225.compute-1.amazonaws.com] /home/onespot/qanat/current/.bundle/environment.rb:137:in `block in patch_rubygems'
 ** [out :: ec2-174-129-48-225.compute-1.amazonaws.com] : undefined method `name=' for #<Gem::LoadError:0x00000000a20728> (NoMethodError)
 ** [out :: ec2-174-129-48-225.compute-1.amazonaws.com] from /home/onespot/.bundle/ruby/1.9.1/gems/daemon-kit-0.1.7.12/vendor/tmail.rb:5:in `<top (required)>'
 ** [out :: ec2-174-129-48-225.compute-1.amazonaws.com] from /home/onespot/.bundle/ruby/1.9.1/gems/daemon-kit-0.1.7.12/lib/daemon_kit/error_handlers/mail.rb:1:in `require'
 ** [out :: ec2-174-129-48-225.compute-1.amazonaws.com] from /home/onespot/.bundle/ruby/1.9.1/gems/daemon-kit-0.1.7.12/lib/daemon_kit/error_handlers/mail.rb:1:in `<top (required)>'
 ** [out :: ec2-174-129-48-225.compute-1.amazonaws.com] from /home/onespot/.bundle/ruby/1.9.1/gems/daemon-kit-0.1.7.12/lib/daemon_kit/safety.rb:84:in `require'

This is a bug

If you don't own the IO object, you have no idea what it may be used for nor the consequence to the process of closing it. Why is this code here?

Ruby processes generally can only peg one CPU. I'd like to be able to create 4 instances of my Ruby daemon so that I can peg the 4 cores on an EC2 large instance. This is hindered by the fact that the daemon writes its PID file to shared/log/name.pid and logfile to shared/log/env.log. Ideally this should be a log and pid file per instance.

If DK already supports this, any tips or docs on how to do this would also be appreciated.

We seem to be having issues getting certain gems to be loaded correctly. We've been trying to build twitter and superfeedr daemons but our libexec code can't seem to find the gem. The gems have been added in the Gemfile and the pre-daemonize require doesn't raise an error.

When we run the daemon we get this error:

[daemon-kit]: DaemonKit (0.1.8.1) booting in development mode
[daemon-kit]: Setting up trap for USR1
[daemon-kit]: Setting up trap for USR2
[daemon-kit]: Setting up trap for HUP
[daemon-kit]: Setting up trap for INT
[daemon-kit]: Setting up trap for TERM
[daemon-kit]: DaemonKit (0.1.8.1) booted, now running twitter-stream
[daemon-kit]: Running shutdown hooks
[daemon-kit]: Shutting down twitter-stream
/Users/hunter/Sites/active/infinite.ly/daemons/twitter_stream/libexec/twitter_stream-daemon.rb:16:in '': uninitialized constant TweetStream (NameError)
        from /Users/hunter/.rvm/gems/ruby-1.9.2-p0/gems/daemon-kit-0.1.8.1/lib/daemon_kit/application.rb:38:in 'require'
        from /Users/hunter/.rvm/gems/ruby-1.9.2-p0/gems/daemon-kit-0.1.8.1/lib/daemon_kit/application.rb:38:in 'run'
        from /Users/hunter/.rvm/gems/ruby-1.9.2-p0/gems/daemon-kit-0.1.8.1/lib/daemon_kit/application.rb:21:in 'exec'
        from bin/twitter_stream:7:in `'

The libexec code is straightforward:

DaemonKit::Application.running! do |config|
end

TweetStream::Client.new('user','pass', :yajl).on_delete{ |status_id, user_id|
  # Delete
}.on_limit { |skip_count|
  # do something
}.filter(:track => 'video') do |status, client|
  puts status.inspect
end

What we did find strange was that certain libraries work and others don't. With twitter we've only tried the tweetstream library but when building a superfeedr daemon, the superfeedr-rb library works with no issue but the superfeedr-ruby library doesn't.

We're running ruby 1.9.2 (via rvm) with bundler 1.0.

Just helped @ranaldobowker debug an issue where a config file loaded by DaemonKit::Config was missing the correct environment name in the top-level of the YAML file, and subsequently blew up badly.

The offending lines in DaemonKit::Config#initialize tests for the presence of the DAEMON_ENV in the hash, and pulls that up one level.

Although this was probably amazing at the time, I think this magic is no longer good practice... We need to figure out how we can improve this and safeguard users from pulling out their hair...

@marcbowes any ideas?

Hi,

I couldn't start rake spec, I had the following message :

[root@localhost test_app]# rake spec
(in /home/me/test_app)
To use rspec for testing you must install rspec gem:
    gem install rspec`

But :

 gem list

 *** LOCAL GEMS ***
 rspec (2.0.0.beta.19, 1.3.0, 1.2.9)
 rspec-core (2.0.0.beta.19)
 rspec-expectations (2.0.0.beta.19)
 rspec-mocks (2.0.0.beta.19)
 rspec-rails (1.3.2, 1.2.9)

And :

bundle install
Using eventmachine (0.12.10) 
Using daemon-kit (0.1.8.1) 
Using rack (1.2.1) 
Using rspec (1.3.0) 
Using bundler (1.0.0.rc.2) 
Your bundle is complete! Use `bundle show [gemname]` to see where a bundled gem is installed.

I didn't add any code at this time.

I had to add in Gemfile:
gem 'rake'

I'm having problems with capistrano on the latest daemon-kit release.
Versions:
OS X 10.6.2
ruby 1.8.7 (2009-06-08 patchlevel 173) [universal-darwin10.0]
daemon-kit (0.1.8rc3) - latest from git
capistrano (2.5.18, 2.5.2) - 2.5.2 is the OS X default
capistrano-ext (1.2.1)

How to reproduce:

r2d2:tmp edennis$ daemon-kit testing -i default -d capistrano
create
create README
create Rakefile
create Gemfile
create bin
create bin/testing
create config
create config/arguments.rb
create config/boot.rb
create config/environment.rb
create config/environments/development.rb
create config/environments/production.rb
create config/environments/test.rb
create config/post-daemonize/readme
create config/pre-daemonize/readme
create script
create script/console
create script/destroy
create script/generate
create tasks
create log
create tmp
create vendor
create lib
create lib/testing.rb
create libexec
create libexec/testing-daemon.rb
create Capfile
exist config
create config/deploy/logrotate.erb
create config/deploy/production.rb
create config/deploy/staging.rb
create config/deploy.rb
create config/environments/staging.rb
create spec
create spec/testing_spec.rb
create spec/spec.opts
create spec/spec_helper.rb
exist tasks
create tasks/rspec.rake
r2d2:tmp edennis$ cd testing
You have new mail in /var/mail/edennis
r2d2:testing edennis$ cap -T
/Library/Ruby/Gems/1.8/gems/capistrano-2.5.18/lib/capistrano/
configuration/loading.rb:152:in require': no such file to load -- capistrano/recipes/deploy/scm (LoadError) from /Library/Ruby/Gems/1.8/gems/capistrano-2.5.18/lib/capistrano/ configuration/loading.rb:152:inrequire'
from /Users/edennis/.bundle/ruby/1.8/gems/daemon-kit-0.1.7.12/lib/
daemon_kit/deployment/capistrano.rb:2:in load' from /Library/Ruby/Gems/1.8/gems/capistrano-2.5.18/lib/capistrano/ configuration/loading.rb:172:inload_from_file'
from /Library/Ruby/Gems/1.8/gems/capistrano-2.5.18/lib/capistrano/
configuration/loading.rb:89:in load' from /Library/Ruby/Gems/1.8/gems/capistrano-2.5.18/lib/capistrano/ configuration/loading.rb:86:inload'
from /Library/Ruby/Gems/1.8/gems/capistrano-2.5.18/lib/capistrano/
configuration/loading.rb:86:in each' from /Library/Ruby/Gems/1.8/gems/capistrano-2.5.18/lib/capistrano/ configuration/loading.rb:86:inload'
from Capfile:7:in load' from /Library/Ruby/Gems/1.8/gems/capistrano-2.5.18/lib/capistrano/ configuration/loading.rb:172:inload_from_file'
from /Library/Ruby/Gems/1.8/gems/capistrano-2.5.18/lib/capistrano/
configuration/loading.rb:89:in load' from /Library/Ruby/Gems/1.8/gems/capistrano-2.5.18/lib/capistrano/ configuration/loading.rb:86:inload'
from /Library/Ruby/Gems/1.8/gems/capistrano-2.5.18/lib/capistrano/
configuration/loading.rb:86:in each' from /Library/Ruby/Gems/1.8/gems/capistrano-2.5.18/lib/capistrano/ configuration/loading.rb:86:inload'
from /Library/Ruby/Gems/1.8/gems/capistrano-2.5.18/lib/capistrano/cli/
execute.rb:65:in load_recipes' from /Library/Ruby/Gems/1.8/gems/capistrano-2.5.18/lib/capistrano/cli/ execute.rb:65:ineach'
from /Library/Ruby/Gems/1.8/gems/capistrano-2.5.18/lib/capistrano/cli/
execute.rb:65:in load_recipes' from /Library/Ruby/Gems/1.8/gems/capistrano-2.5.18/lib/capistrano/cli/ execute.rb:31:inexecute!'
from /Library/Ruby/Gems/1.8/gems/capistrano-2.5.18/lib/capistrano/cli/
execute.rb:14:in execute' from /Library/Ruby/Gems/1.8/gems/capistrano-2.5.18/bin/cap:4 from /usr/bin/cap:19:inload'

from /usr/bin/cap:19

Capistrano works fine for several other projects I have on this
workstation; daemon-kit is the only software that is exhibiting this
behavior.

0.2.3 has been here forever, and 0.3.0-rc2 is over half a year old. Time to release a new gem?

DK requires rubigen, which requires Rails 2.2.2 or greater. I'd like to see the rubigen requirement moved to a development dependency so generated daemons can use earlier versions of Rails.

What do you think of defaulting to the help output rather than running the daemon?

Depending on foreman allows us to leverage a Procfile, .env and a load of generators for process supervision tools. See https://github.com/ddollar/foreman/tree/master/data/export for the work being done there. We could add our monit/god templates as custom exporters to foreman.

Wdyt?

In your blog post you say you've now added Rails "support". Can you please explain how to use it, I cannot find any documentation about it.
Basically I want my daemon to run in the environment of my rails 3 app (so it can access models etc.).

Thank you!

'bin/<daemon_name> run -e production' says "Booting <daemon_name> in development mode".

It attempts to require 'cucumber/version', which doesn't appear to exist anymore. This file was removed in Cucumber commit aslakhellesoy/cucumber@65a9c2329e2fe7cc15cb7aa89a2ae5d79482939d .

Monit sets an extremely limited PATH environment for scripts it runs. If you are using REE or installed ruby in /usr/local/bin the monit script daemon kit generates will fail silently.

To resolve I needed to explicity add the ruby command to the start and stop command:

/usr/local/bin/ruby

e.g.

start program = "/usr/bin/env DAEMON_ENV=production /usr/local/bin/ruby /home/rails/foobardaemon/current/bin/foobardaemon start" as uid rails and gid rails

Also, the monit generation scripts generate a path which points to a SPECIFIC release. It is better to instead point to the /current/ path for the start/stop/and PID. Otherwise you would be required to push a new monit file on each daemon kit cap deploy, put it in the right place, and restart the remote monit server.

Cheers! (I love daemon-kit BTW!)

RubyGems.org doesn't report a license for your gem. This is because it is not specified in the gemspec of your last release.

via e.g.

spec.license = 'MIT'
# or
spec.licenses = ['MIT', 'GPL-2']

Including a license in your gemspec is an easy way for rubygems.org and other tools to check how your gem is licensed. As you can image, scanning your repository for a LICENSE file or parsing the README, and then attempting to identify the license or licenses is much more difficult and more error prone. So, even for projects that already specify a license, including a license in your gemspec is a good practice. See, for example, how rubygems.org uses the gemspec to display the rails gem license.

There is even a License Finder gem to help companies/individuals ensure all gems they use meet their licensing needs. This tool depends on license information being available in the gemspec. This is an important enough issue that even Bundler now generates gems with a default 'MIT' license.

I hope you'll consider specifying a license in your gemspec. If not, please just close the issue with a nice message. In either case, I'll follow up. Thanks for your time!

Appendix:

If you need help choosing a license (sorry, I haven't checked your readme or looked for a license file), GitHub has created a license picker tool. Code without a license specified defaults to 'All rights reserved'-- denying others all rights to use of the code.
Here's a list of the license names I've found and their frequencies

p.s. In case you're wondering how I found you and why I made this issue, it's because I'm collecting stats on gems (I was originally looking for download data) and decided to collect license metadata,too, and make issues for gemspecs not specifying a license as a public service :). See the previous link or my blog post aobut this project for more information.

I enabled the hoptoad safety net. The exceptions still stay in my application logs and I get the following lines after the stacktrace. Any ideas?

2009-10-11 03:40:58.355460 nanite_video(24925) [ERROR] hoptoad.rb:31: Hoptoad Failure: Net::HTTPClientError
Invalid notice format. Please check http://hoptoadapp.com/pages/api for more information.

Hello!

With Ruby 2, AMQP daemons doesn't react well to Ctrl-C.

DaemonKit::Application.running! do |config|
  config.trap('TERM') do
    puts 'Going down.'
  end
end

DaemonKit::AMQP.run do |connection|
  puts "I'm running..."
end

And when I run it then shut it down…

$ bin/communication_server
[daemon-kit]: DaemonKit (0.2.3) booting in development mode
[daemon-kit]: Setting up trap for USR1
[daemon-kit]: Setting up trap for USR2
[daemon-kit]: Setting up trap for HUP
[daemon-kit]: Setting up trap for INT
[daemon-kit]: Setting up trap for TERM
[daemon-kit]: DaemonKit (0.2.3) booted, now running seelies_communication_server
[daemon-kit]: AMQP.start({:user=>"guest", :pass=>"guest", :host=>"localhost", :vhost=>"/"})
I'm running...
^Clog writing failed. can't be called from trap context
[daemon-kit]: Running signal traps for INT
[daemon-kit]: Running shutdown hooks
[daemon-kit]: Shutting down seelies_communication_server
/Users/romaintribes/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/eventmachine-1.0.3/lib/eventmachine.rb:1087:in `synchronize': can't be called from trap context (ThreadError)
    from /Users/romaintribes/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/eventmachine-1.0.3/lib/eventmachine.rb:1087:in `next_tick'
    from /Users/romaintribes/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/amqp-1.0.2/lib/amqp/connection.rb:63:in `stop'
    from /Users/romaintribes/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/daemon-kit-0.2.3/lib/daemon_kit/dk_amqp.rb:31:in `block in run'
    from /Users/romaintribes/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/daemon-kit-0.2.3/lib/daemon_kit/initializer.rb:346:in `call'
    from /Users/romaintribes/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/daemon-kit-0.2.3/lib/daemon_kit/initializer.rb:346:in `block in run_traps'
    from /Users/romaintribes/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/daemon-kit-0.2.3/lib/daemon_kit/initializer.rb:346:in `each'
    from /Users/romaintribes/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/daemon-kit-0.2.3/lib/daemon_kit/initializer.rb:346:in `run_traps'
    from /Users/romaintribes/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/daemon-kit-0.2.3/lib/daemon_kit/initializer.rb:354:in `block in set_trap'
    from /Users/romaintribes/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/eventmachine-1.0.3/lib/eventmachine.rb:187:in `call'
    from /Users/romaintribes/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/eventmachine-1.0.3/lib/eventmachine.rb:187:in `run_machine'
    from /Users/romaintribes/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/eventmachine-1.0.3/lib/eventmachine.rb:187:in `run'
    from /Users/romaintribes/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/amqp-1.0.2/lib/amqp/connection.rb:38:in `start'
    from /Users/romaintribes/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/daemon-kit-0.2.3/lib/daemon_kit/dk_amqp.rb:36:in `run'
    from /Users/romaintribes/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/daemon-kit-0.2.3/lib/daemon_kit/dk_amqp.rb:21:in `run'
    from /Users/romaintribes/Seelies/communication_server/libexec/communication_server-daemon.rb:6:in `<top (required)>'
    from /Users/romaintribes/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/activesupport-4.0.0/lib/active_support/dependencies.rb:228:in `require'
    from /Users/romaintribes/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/activesupport-4.0.0/lib/active_support/dependencies.rb:228:in `block in require'
    from /Users/romaintribes/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/activesupport-4.0.0/lib/active_support/dependencies.rb:213:in `load_dependency'
    from /Users/romaintribes/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/activesupport-4.0.0/lib/active_support/dependencies.rb:228:in `require'
    from /Users/romaintribes/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/daemon-kit-0.2.3/lib/daemon_kit/application.rb:38:in `run'
    from /Users/romaintribes/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/daemon-kit-0.2.3/lib/daemon_kit/application.rb:21:in `exec'
    from bin/communication_server:3:in `<main>'

Searching for this error led me to this Ruby ticket (https://bugs.ruby-lang.org/issues/7917) that states the error is code-related.

Do you have any idea about how to fix it?

There's a syslog module in STDLIB.

Does the syslog-logger gem have functionality that is missing from the STDLIB implementation?

So when I run a daemon using the following command
./bin/some_daemon start --pid /tmp/blah.pid
The pid file would be dropped in #{DAEMON_ROOT}/log/ instead of the expected /tmp directory.
I found this piece of code in the daemon-kit/lib/daemon_kit/initializer.rb file,
def parse_arguments!
return unless own_args?

own_args? is this pretty little method,
def own_args?
Arguments.parser_available
end

Arguments.parser_available gets set to false by default but I'm not sure how to set it to true when I want to parse command line arguments. Naturally I commented it out. Could you please explain how to use command line arguments in this way?

Thanks for a great gem. Very useful.

In the generated daemon-kit application, the script/generate and script/destroy files have identical contents:

#!/usr/bin/env ruby
require File.expand_path( '../../config/environment', __FILE__ )
require 'daemon_kit/commands/generate'

I believe that the script/destroy script should require 'daemon-kit/commands/destroy' instead of 'daemon-kit/commands/generate', unless it is using some ARGV[0]-magic to detect the behavior to follow.

Ran into this issue when trying to update from 2.3 to 3.1:

$ bundle exec rake
rake aborted!
NameError: uninitialized constant Class::ERB
/Users/me/.rvm/gems/ruby-2.1.1/gems/daemon-kit-0.3.1/lib/daemon_kit/config.rb:32:in `load'
/Users/me/.rvm/gems/ruby-2.1.1/gems/daemon-kit-0.3.1/lib/daemon_kit/config.rb:39:in `hash'
/Users/me/work/sailthru-daemon/config/pre-daemonize/sailthru-daemon.rb:1:in `<top (required)>'
/Users/me/.rvm/gems/ruby-2.1.1/gems/daemon-kit-0.3.1/lib/daemon_kit/initializer.rb:156:in `require'
/Users/me/.rvm/gems/ruby-2.1.1/gems/daemon-kit-0.3.1/lib/daemon_kit/initializer.rb:156:in `block in load_predaemonize_configs'
/Users/me/.rvm/gems/ruby-2.1.1/gems/daemon-kit-0.3.1/lib/daemon_kit/initializer.rb:153:in `each'
/Users/me/.rvm/gems/ruby-2.1.1/gems/daemon-kit-0.3.1/lib/daemon_kit/initializer.rb:153:in `load_predaemonize_configs'
/Users/me/.rvm/gems/ruby-2.1.1/gems/daemon-kit-0.3.1/lib/daemon_kit/initializer.rb:100:in `before_daemonize'
/Users/me/.rvm/gems/ruby-2.1.1/gems/daemon-kit-0.3.1/lib/daemon_kit/initializer.rb:53:in `run'
/Users/me/work/sailthru-daemon/config/boot.rb:25:in `run'
/Users/me/work/sailthru-daemon/config/boot.rb:13:in `boot!'
/Users/me/work/sailthru-daemon/config/boot.rb:50:in `<top (required)>'
/Users/me/work/sailthru-daemon/Rakefile:1:in `require'
/Users/me/work/sailthru-daemon/Rakefile:1:in `<top (required)>'
/Users/me/.rvm/gems/ruby-2.1.1/bin/ruby_executable_hooks:15:in `eval'
/Users/me/.rvm/gems/ruby-2.1.1/bin/ruby_executable_hooks:15:in `<main>'
(See full trace by running task with --trace)

Looks like something's missing!

Pidfile should be specified by "--pid", but thats not working properly because https://github.com/kennethkalmer/daemon-kit/blob/master/lib/daemon_kit/arguments.rb#L86 handles only "--pidfile".

running 'rake daemon_kit:freeze:gems' doesn't unpack the gem into the vendor/daemon_kit dir, but instead to a sub-directory of daemon_kit which is not the location boot.rb expects to find it in.

What is the forecast for this project? thanks

When I run the rake task to freeze daemon-kit to vendor, it puts the gem in vendor/daemon_kit/daemon_kit/.....

This does not work for systems like monit, where it tries to validate the cmd and complains that there is no such binary DAEMON_ENV:

DAEMON_ENV=staging bin/foo

I would like to see something like Rails' script/server:

bin/foo -e staging

The DK help says that this is supported but it does not appear to work.

I'm starting my daemon with ./bin/foo run, and according to this line I would expect to see a pidfile in the log directory, but can't find one there.

I also tried starting the daemon with ./bin/foo run --pidfile /tmp/foo.pid, and don't see a pidfile there either.

In order to see if the default was being set as suggested in initializer.rb, I added a test in initializer_spec.rb that looks like this:

  it "should have a default pid file" do
    @configuration.pid_file.should_not be_nil
  end

This blows up with the following:

     ArgumentError:
       wrong number of arguments (0 for 1)
     # ./lib/daemon_kit/initializer.rb:329:in `pid_file'

Looking at line 329 that does make sense:
https://github.com/kennethkalmer/daemon-kit/blob/master/lib/daemon_kit/initializer.rb#L328

Am I doing it wrong? Is this a bug? If so, I'd be happy to provide a fix, but I'd need a pointer in the direction of how it's intended to be wired together.

After a
cap deploy
a 'restart' task is run. This task runs a 'stop' presumably followed by a 'start'. The 'stop' command fails with the message:
Could not locate Gemfile

I'm guessing this has something to do with the load path? When I'm running:
/var/www/calculator.delaagsterekening.nl/httpdocs/current/bin/dlr-calculator
the same error occurs. When I run:
cd /var/www/calculator.delaagsterekening.nl/httpdocs/current && bin/dlr-calculator
Everything is fine.

Stacktrace:
** [out :: staging.delaagsterekening.nl] /opt/ruby1.9.1p378/lib/ruby/gems/1.9.1/gems/bundler-1.0.2/lib/bundler/shared_helpers.rb:21:in default_gemfile' ** [out :: staging.delaagsterekening.nl] : ** [out :: staging.delaagsterekening.nl] Could not locate Gemfile ** [out :: staging.delaagsterekening.nl] ( ** [out :: staging.delaagsterekening.nl] Bundler::GemfileNotFound ** [out :: staging.delaagsterekening.nl] ) ** [out :: staging.delaagsterekening.nl] from /opt/ruby1.9.1p378/lib/ruby/gems/1.9.1/gems/bundler-1.0.2/lib/bundler.rb:187:indefault_gemfile'
** [out :: staging.delaagsterekening.nl] from /opt/ruby1.9.1p378/lib/ruby/gems/1.9.1/gems/bundler-1.0.2/lib/bundler.rb:157:in root' ** [out :: staging.delaagsterekening.nl] from /opt/ruby1.9.1p378/lib/ruby/gems/1.9.1/gems/bundler-1.0.2/lib/bundler.rb:116:inload'
** [out :: staging.delaagsterekening.nl] from /opt/ruby1.9.1p378/lib/ruby/gems/1.9.1/gems/bundler-1.0.2/lib/bundler.rb:100:in setup' ** [out :: staging.delaagsterekening.nl] from /var/www/calculator.delaagsterekening.nl/httpdocs/current/config/boot.rb:12:inrescue in <top (required)>'
** [out :: staging.delaagsterekening.nl] from /var/www/calculator.delaagsterekening.nl/httpdocs/current/config/boot.rb:7:in <top (required)>' ** [out :: staging.delaagsterekening.nl] from /var/www/calculator.delaagsterekening.nl/httpdocs/current/config/environment.rb:7:inrequire'
** [out :: staging.delaagsterekening.nl] from /var/www/calculator.delaagsterekening.nl/httpdocs/current/config/environment.rb:7:in <top (required)>' ** [out :: staging.delaagsterekening.nl] from /var/www/calculator.delaagsterekening.nl/httpdocs/current/bin/dlr-calculator:6:inrequire'
** [out :: staging.delaagsterekening.nl] from /var/www/calculator.delaagsterekening.nl/httpdocs/current/bin/dlr-calculator:6:in `

Bundler 1.0.2
Daemon-kit 0.1.8.1
Capistrano 2.5.19

I generated a sample daemon application and noticed that the generated specs (in the spec directory) are not compatible with rspec 2. So I modified the templates to produce rspec2 compatible files. You will find patch attached to this ticket.

Please also note the require...boot line (at the top of the sample application's Rakefile) breaks any rake task because of "stack level too deep". I am using ruby 1.9.2, gem 1.3.7 and rake 0.9.2 on amd64 linux. I worked around the problem by commenting the offending line, but I don't know if it will have side-effects on other parts of the application.

After patching the rspec generator, rebuilding the daemon-kit gem and reinstalling it, the generated specs now work as expected:

julien@dev:~$ daemon-kit testme -i amqp -t rspec
julien@dev:~$ cd testme
julien@dev:~/testme$ ruby -v
ruby 1.9.2p0 (2010-08-18 revision 29036) [x86_64-linux]
julien@dev:~/testme$ gem -v
1.3.7
julien@dev:~/testme$ gem list | egrep '(rake|rspec)'
rake (0.9.2)
rspec (2.6.0)
rspec-core (2.6.4)
rspec-expectations (2.6.0)
rspec-mocks (2.6.0)
julien@dev:~/testme$ rake spec # big mess with recursive requires ending up in "stack level too deep"
julien@dev:~/testme$ sed -i -e 's/^require.*boot/#&/' Rakefile # workaround the above mess
julien@dev:~/testme$ rake spec
/usr/bin/ruby -S bundle exec rspec --options spec/spec.opts ./spec/testme_spec.rb
F

Failures:

  1) Place your specs here find this spec in spec directory
     Failure/Error: violated "Be sure to write your specs"
     NoMethodError:
       undefined method `violated' for #<RSpec::Core::ExampleGroup::Nested_1:0x0000000185afd8>
     # ./spec/testme_spec.rb:8:in `block (2 levels) in <top (required)>'

Finished in 0.00122 seconds
1 example, 1 failure

Failed examples:

rspec ./spec/testme_spec.rb:7 # Place your specs here find this spec in spec directory
julien@dev:~/testme$

DK should support log rotation so log files don't grow without bounds. Here's some code to do it:

http://gist.github.com/304739

-require File.dirname(__FILE__) + '/../config/boot'
+require File.expand_path('../../config/boot',  __FILE__)

This is in script/console and in the initial bin file created for the application.

-require File.dirname(__FILE__) + '/../config/environment'
+require File.expand_path('../../config/environment',  __FILE__)

It might be needed elsewhere but these changes seem to allow my daemon to run.

http://github.com/jgeiger/daemon-kit/commit/489268fda872dcb734277c6adb858030f2b10594

I'm guessing there are more places (the spec directory) this will need to be updated as well.

21:39 tliff: shouldnt /opt/wtm2/releases/20100129123627/daemon/bin/daemon start --pid /opt/wtm2/shared/pids/daemon.pid put the pidfile at the specified location?
21:40 jmettraux: kennethk_: there is a question for you
21:41 tliff: the daemon script does say "--pidfile PATH" but the argument parser in the gem seems to be looking for "--pid"
21:41 tliff: neither works ;)
21:42 jmettraux: does the /opt/wtm2/shared/pids/ dir exist ?
21:42 tliff: yes
21:42 jmettraux: is there an error message ?
21:42 tliff: nope
21:46 jmettraux: does the default pidfile thing work ?
21:47 tliff: yes
21:47 tliff: creates a pidfile in daemon/log
21:47 jmettraux: write access OK for /opt/wtm2/shared/pids/ ?
21:48 tliff: i'm trying it as root, so yes
21:49 tliff: i can touch the path/file just fine

Hi

Was using 0.1.7.9 with my yml file having keys with hyphens. Upgraded to 0.1.12 and am getting this error

/usr/lib/ruby/gems/1.8/gems/daemon-kit-0.1.7.12/lib/daemon_kit/config.rb:94:in extend_hash': (eval):3:inextend_hash': compile error (SyntaxError)
(eval):1: syntax error
def test-with-hyphen
^
(eval):3: syntax error
from /usr/lib/ruby/gems/1.8/gems/daemon-kit-0.1.7.12/lib/daemon_kit/config.rb:93:in each' from /usr/lib/ruby/gems/1.8/gems/daemon-kit-0.1.7.12/lib/daemon_kit/config.rb:93:inextend_hash'
from /usr/lib/ruby/gems/1.8/gems/daemon-kit-0.1.7.12/lib/daemon_kit/config.rb:89:in data=' from /usr/lib/ruby/gems/1.8/gems/daemon-kit-0.1.7.12/lib/daemon_kit/config.rb:43:ininitialize'
from /usr/lib/ruby/gems/1.8/gems/daemon-kit-0.1.7.12/lib/daemon_kit/config.rb:30:in new' from /usr/lib/ruby/gems/1.8/gems/daemon-kit-0.1.7.12/lib/daemon_kit/config.rb:30:inload'
from /home/glen/projects/verity_4.0/job-controller/config/pre-daemonize/require_gems.rb:1
from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in gem_original_require' ... 9 levels... from ./bin/../config/environment.rb:7:inrequire'
from ./bin/../config/environment.rb:7

Thanks
Glen

you changed

def own_args?

     Arguments.parser_available
   end

from:

   def own_args?
     ![ 'cap' ].include?( File.basename( $0 ) )
   end
[1/7/10 4:51:14 AM] steve: in initializer.rb
[1/7/10 4:51:30 AM] steve: and he doesnt set parser_available to true until after he parses the args
[1/7/10 4:51:40 AM] steve: so none of the cmdline args are used at all

The boot.rb file in app_generators/daemon_kit/templates/config/ directory.
This,
require "#{DAEMON_ROOT}/vendor/daemon_kit/lib/daemon_kit/initializer"
should be this,
require "#{DAEMON_ROOT}/vendor/daemon-kit/lib/daemon_kit/initializer"

Is there a way to use --version in the arguments.rb to serve our own version information? This always seems to trigger daemon-kit's one instead