It depends on which pid file you're referring to. The main server pid
file, tmp/pids/server.pid, will do whatever script/rails server -d
does. It's possible that means it will just do the dumb Mongrel thing.
init.rb:
Rails::Server.new.tap { |server|
require ENV_PATH
Dir.chdir(Rails.application.root)
server.start
}
Stopping:
def stop_server
pid_file = Rails.root.join("tmp", "pids", "server.pid")
if pid_file.exist?
exec "kill -KILL #{pid_file.read.chomp}"
pid_file.delete
end
end
def stop_builders
Rails.root.join("tmp", "pids", "builders").children.each do |pid_file|
Platform.kill_child_process(pid_file.read.chomp)
end
end
The builder files don't try to be smart at all. They will create pid
files as necessary or reuse them if they already exist.
script/builder:
Platform.project_pid_file(project.name).tap do |f|
f.dirname.mkpath
f.open("w") {|f| f.write Process.pid }
end
ProjectBlocker.block(project)
This is exactly the previous pid-creation behavior, except that the
logic has been moved to the builder, and I'm attempting a pid cleanup
as well as the old ProjectBlocker.release on error or interrupt.
Looking more closely at daemon_helper, it's clearly handling a lot of
useful stuff beyond what's in place in init, so it looks like it needs
to be fixed before I can sign off this bug. But I'm confused as to why
you'd keep your pid-management code separate when the use already
expects -d to handle this stuff. What's the benefit?
As a maintainer, I wish there was a lot more test coverage of both
places. :) This my work has not improved.
Cheers,
Brian
On Sun, Jul 3, 2011 at 5:30 PM, Chad Woolley <[email protected]> wrote:
> On Sat, Jul 2, 2011 at 11:37 PM, Brian Guthrie <[email protected]> wrote:
>> Also, as far as I know, we don't need or use anything in the daemon/
>> subdirectory now; we're relying on Rails' server daemonization, the
>> killtree script, and straight-up kill to do the work.
>
> If a process dies or gets killed, and leaves a stale pid file behind,
> is all the pid-handling code smart enough to detect this and recreate
> a new pidfile for the new pid? I.e. we don't act like mongrel, and
> refuse to start with a stale pid?
> _______________________________________________
> Cruisecontrolrb-developers mailing list
> [email protected]
> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>
_______________________________________________
Cruisecontrolrb-developers mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
