Extracted inspector, reaper, spawner into a plugin

rubyonrails-core
1

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

2

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.

3

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?

4

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? :wink: j/k

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

5

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.