CONTROLLERS[:mock_news_sniffer] = DaemonController.new(
:identifier => “RamazeApp”,
:start_command => “ramaze –daemonize start –port 2999 #{app_path}”,
:stop_command => “ramaze –daemonize stop –port 2999 #{app_path}”,
:ping_command => lambda { TCPSocket.new(“localhost”, 2999) },
:pid_file => File.join(Dir.tmpdir, “ramaze.pids/ramaze_app.pid”),
:log_file => File.join(Dir.tmpdir, “ramaze.pids/ramaze_app.log”),
:timeout => 25
)

because it can’t access the lock dir.

But works if you put this in front of it:
FileUtils.mkdir_p(File.join(Dir.tmpdir, “ramaze.pids”))

Otherwise working great for me!

I’m experiencing some heartache with daemon_controller and BackgrounDrb, and was wondering if you (and the rest of the readers) could lend me your eyes. The situation is this: I’m attempting to set BackgrounDrb up as an initializer for my project, and have it configured as follows:

config/backgroundrb.yml:
—
:backgroundrb:
:ip: 0.0.0.0
:port: 11111
:debug_log: true
:log: foreground # log to console

intializers/backgroundrb.rb:
BACKGROUNDRB_PORT = 11111

backgroundrb = DaemonController.new(
:identifier => ‘BackgrounDrb job server/scheduler’,
:start_command => ’script/backgroundrb start’,
:stop_command => ’script/backgroundrb stop’,
:ping_command => lambda { TCPSocket.new(‘localhost’, BACKGROUNDRB_PORT) },
:pid_file => “tmp/pids/backgroundrb_#{BACKGROUNDRB_PORT}.pid”,
:log_file => “log/backgroundrb_#{BACKGROUNDRB_PORT}.log”,
:log_file_activity_timeout => 20
)

backgroundrb.start unless backgroundrb.running?

When I attempt to fire up the web server, it bombs with the following backtrace:
** Starting Rails with development environment…
(wait 15 seconds)
Exiting
[...]/plugins/daemon_controller/lib/daemon_controller.rb:321:in `start_without_locking’: Daemon ‘BackgrounDrb job server/scheduler’ failed to start in time. (DaemonController::StartTimeout)
from [...]/plugins/daemon_controller/lib/daemon_controller.rb:163:in `start’
from [...]/plugins/daemon_controller/lib/daemon_controller/lock_file.rb:34:in `exclusive_lock’
from [...]/plugins/daemon_controller/lib/daemon_controller/lock_file.rb:29:in `open’
from [...]/plugins/daemon_controller/lib/daemon_controller/lock_file.rb:29:in `exclusive_lock’
from [...]/plugins/daemon_controller/lib/daemon_controller.rb:162:in `start’
from [...]/config/initializers/backgroundrb.rb:14

There are two oddities that I noticed while trying to get to the root cause of this problem:
1) The ruby process for the BackgrounDrb daemon starts the same way I would normally run it by hand, save for the timeout. With the exception originating in file locking territory, this makes me think BackgrounDrb is causing the issue, yet I know that version 1.0.4 requires no args other that ’start’ to start it.
2) If I start BackgrounDrb manually from a console, and then load its DaemonController declaration into an irb session, I can stop/start it as one would expect.

Thanks for a great daemon management solution,
–
-gary

For production, then yes, I’ll be using god for handling the daemons.

Does passenger support trapping of any signals? (i.e. could I trap a USR1/2 signal to restart the daemons?)

Yeah, I’m on IRC from time to time. My nick is FooBarWidget, irc.freenode.net. Usually in #passenger, #rails-contrib or #rubyonrails.