From btguthrie at gmail.com  Sun Jul  3 02:37:22 2011
From: btguthrie at gmail.com (Brian Guthrie)
Date: Sun, 3 Jul 2011 16:37:22 +1000
Subject: [Cruisecontrolrb-developers] Some updates,
	and a couple of test requests
Message-ID: <CAKJ84juezCm6cMM4UC0=DPTY0u=4AyPpdMmTHyk_EY0pcu7Y9w@mail.gmail.com>

I did some work today to try to fix Cruise daemonization. Everything
looks ok to me on my Mac and Ruby 1.9.2 but I'm having trouble
installing and running JRuby locally. If others could take a poke at
this I'd greatly appreciate it.

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.

The init.rb#stop_server method is using kill -KILL rather than kill
-INT, which is what I'd prefer, because shutting down the process
using -INT while the server is daemonized in Prod mode seems to cause
an infinite loop that I haven't locked down yet. Doesn't seem to
happen in dev mode.

Builders are now creating and cleaning up their own pid files, rather
than Platform creating the pid files at builder start time (and
getting cleaned up, well, never). If someone could explain why Cruise
is creating and using both .pid files and individual builder.lock
files that would be extremely helpful to me as a maintainer, since I
wasn't around for the creation of that code.

After this, nothing much is keeping us from cutting an RC1.

Brian

From thewoolleyman at gmail.com  Sun Jul  3 03:30:44 2011
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Sun, 3 Jul 2011 00:30:44 -0700
Subject: [Cruisecontrolrb-developers] Some updates,
	and a couple of test requests
In-Reply-To: <CAKJ84juezCm6cMM4UC0=DPTY0u=4AyPpdMmTHyk_EY0pcu7Y9w@mail.gmail.com>
References: <CAKJ84juezCm6cMM4UC0=DPTY0u=4AyPpdMmTHyk_EY0pcu7Y9w@mail.gmail.com>
Message-ID: <CA+jPR43jUPY=aPR4ANHzkr-rZ0FRx4oFVtO_X1zPpqN1svCGag@mail.gmail.com>

On Sat, Jul 2, 2011 at 11:37 PM, Brian Guthrie <btguthrie at gmail.com> 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?

From btguthrie at gmail.com  Sun Jul  3 05:46:53 2011
From: btguthrie at gmail.com (Brian Guthrie)
Date: Sun, 3 Jul 2011 19:46:53 +1000
Subject: [Cruisecontrolrb-developers] Some updates,
	and a couple of test requests
In-Reply-To: <CA+jPR43jUPY=aPR4ANHzkr-rZ0FRx4oFVtO_X1zPpqN1svCGag@mail.gmail.com>
References: <CAKJ84juezCm6cMM4UC0=DPTY0u=4AyPpdMmTHyk_EY0pcu7Y9w@mail.gmail.com>
	<CA+jPR43jUPY=aPR4ANHzkr-rZ0FRx4oFVtO_X1zPpqN1svCGag@mail.gmail.com>
Message-ID: <CAKJ84jtw_Z0=y-0J9g9fbQxqea8PLpnoEsiOnt9O9wgThjcwsw@mail.gmail.com>

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 <thewoolleyman at gmail.com> wrote:
> On Sat, Jul 2, 2011 at 11:37 PM, Brian Guthrie <btguthrie at gmail.com> 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
> Cruisecontrolrb-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>

From btguthrie at gmail.com  Sun Jul  3 09:18:16 2011
From: btguthrie at gmail.com (Brian Guthrie)
Date: Sun, 3 Jul 2011 23:18:16 +1000
Subject: [Cruisecontrolrb-developers] Some updates,
	and a couple of test requests
In-Reply-To: <CAKJ84jtw_Z0=y-0J9g9fbQxqea8PLpnoEsiOnt9O9wgThjcwsw@mail.gmail.com>
References: <CAKJ84juezCm6cMM4UC0=DPTY0u=4AyPpdMmTHyk_EY0pcu7Y9w@mail.gmail.com>
	<CA+jPR43jUPY=aPR4ANHzkr-rZ0FRx4oFVtO_X1zPpqN1svCGag@mail.gmail.com>
	<CAKJ84jtw_Z0=y-0J9g9fbQxqea8PLpnoEsiOnt9O9wgThjcwsw@mail.gmail.com>
Message-ID: <CAKJ84jt-GG1P+A8AeKFe_50SE_BN0k3tUOo1PU0kBt3j6CT7hg@mail.gmail.com>

c.f. https://github.com/thoughtworks/cruisecontrol.rb/commit/17ca0f8b3f03e166fe1d6f240e1ef45c5e604a8a

On Sun, Jul 3, 2011 at 7:46 PM, Brian Guthrie <btguthrie at gmail.com> 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 <thewoolleyman at gmail.com> wrote:
>> On Sat, Jul 2, 2011 at 11:37 PM, Brian Guthrie <btguthrie at gmail.com> 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
>> Cruisecontrolrb-developers at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>>
>