c.f. https://github.com/thoughtworks/cruisecontrol.rb/commit/17ca0f8b3f03e166fe1d6f240e1ef45c5e604a8a
On Sun, Jul 3, 2011 at 7:46 PM, Brian Guthrie <[email protected]> wrote: > 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
