Extracted inspector, reaper, spawner into a plugin

[Mislav Marohnić]

Re: github.com/rails/rails/commit/3b3c05

Says process scripts were extracted to github.com/rails/irs_process_scripts, but that repo hasn't been pushed to. Did DHH forget?

What was the reason for this change; because it wasn't portable (unix only)? Has it something to do with moving over to Rack? Default Capistrano recipe kinda relies on these and I use them in most of my projects that aren't on Passenger.

Thanks,

# Mislav

[Michael Koziarski]

On Mon, Dec 1, 2008 at 11:05 AM, Mislav Marohnić
<mislav....@gmail.com> wrote:
> Re: github.com/rails/rails/commit/3b3c05
> Says process scripts were extracted to github.com/rails/irs_process_scripts,
> but that repo hasn't been pushed to. Did DHH forget?

Seems like it.

> What was the reason for this change; because it wasn't portable (unix only)?
> Has it something to do with moving over to Rack?

They're not particularly portable, nor are they particularly useful.
Every project I've worked on uses some other method of process
spawning and monitoring. Monit, God, Runit, mongrel_cluster, etc.
Shipping with a mostly-broken set of scripts doesn't seem like
something we should do.

2.3 is probably a while off, so hopefully the cobwebs get blown out
and no one even notices :).

> Default Capistrano recipe
> kinda relies on these and I use them in most of my projects that aren't on
> Passenger.

I think we'll send jamis some patches to change the default capistrano
recipes, or remove them entirely, or something.

> # Mislav
>
>
>
> >
>

--
Cheers

Koz

[Dee Zsombor]

Michael Koziarski wrote:

> They're not particularly portable, nor are they particularly useful.
> Every project I've worked on uses some other method of process
> spawning and monitoring. Monit, God, Runit, mongrel_cluster, etc.
> Shipping with a mostly-broken set of scripts doesn't seem like
> something we should do.

I could say the contrary, on every project with a solid Mongrel or FCGI
based setup the spawner script was used. It requires no extra
configuration unlike monit/god/runit. It also cares for safely exiting a
process *after* the current request was processed unlike the defaults for
monit/god/runit etc.

The same can be said about reaper, it *always* works as long as you invoke
it with a /full/path/to/current/process/reaper.

In what way did you find them to be broken?

--
Company - http://primalgrasp.com
Thoughts - http://deezsombor.com

[Mislav Marohnić]

On Tue, Dec 2, 2008 at 22:28, Dee Zsombor <dee.z...@gmail.com> wrote:

I could say the contrary, on every project with a solid Mongrel or FCGI
based setup the spawner script was used. It requires no extra
configuration unlike monit/god/runit. It also cares for safely exiting a
process *after* the current request was processed unlike the defaults for
monit/god/runit etc.

In what way did you find them to be broken?

What Koz meant is that with Mongrels you always need a monitoring daemon in production (otherwise you'll be miserable). Because the monitoring software already knows how to start/stop/restart mongrels (because you've configured it), it's best practice to simply use that for managing Mongrels. We are using god in the company and now that these scripts are gone, we're switching to managing deployments through god because it kinda feels right.

Also, the limitation of these scripts compared to, say, mongrel_cluster was that you couldn't specify unix user/group for processes.

Also, Koz likes Passenger very much and Rails is opinionated, remember? ;)  j/k

To conclude, I have nothing against this change, I just wanted to be sure why it was done.

[Dee Zsombor]

Mislav Marohnić wrote:
> What Koz meant is that with Mongrels you always need a monitoring daemon
> in production (otherwise you'll be miserable). Because the monitoring
> software already knows how to start/stop/restart mongrels (because
> you've configured it), it's best practice to simply use that for
> managing Mongrels. We are using god in the company and now that these
> scripts are gone, we're switching to managing deployments through god
> because it kinda feels right.

Spawner *is a monitoring superb daemon*, as long as you start Mongrels as
described in:

http://capify.org/getting-started/from-the-beginning

instead of relying on mongrel_rails.