Init.d script for Mongrel?

Hi,

I can’t seem to find an example of startup, restart, reload, script for
Mongrel. So here is my little thing I uses.

http://rubyforge.org/snippet/detail.php?type=snippet&id=260

Cheers,

Hi Philippe,

I can’t seem to find an example of startup, restart, reload, script for
Mongrel.

Check my script, which also could selectively start/stop/restart
Mongrel instances. It’s reported here:
http://rubyforge.org/pipermail/mongrel-users/2007-December/004705.html

Paolo C. wrote:


Mongrel-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/mongrel-users

Yes, nice, It does not allow to have different administrators for
different domains contained into their own environments though. I prefer
to use apache as a front end for virtual hosting and using mongrel as an
internal relay. I’ll try a mixed version.

Cheers,

Philippe

On Wed, Feb 6, 2008 at 2:08 AM, Philippe Laliberte
[email protected] wrote:

Hi,

I can’t seem to find an example of startup, restart, reload, script for
Mongrel. So here is my little thing I uses.

http://rubyforge.org/snippet/detail.php?type=snippet&id=260

I prefer supervised services via runit, myself.

http://smarden.org/runit/

Mike

Yes, nice, It does not allow to have different administrators for different
domains contained into their own environments though.

It could do if you have /etc/mongrel accessible by the other
administrators (i.e.: chmod ugo+x /etc/mongrel chmod u+s /etc/mongrel,
so it works a la /tmp way). Otherwise you could change the script so
instead of looking in /etc/mongrel it will looks in $HOME/mongrel o
whatever, for the values of $HOME you prefer.

I prefer to use apache
as a front end for virtual hosting and using mongrel as an internal relay.
I’ll try a mixed version.

This is exactly what we do in production, the script only activates
the mongrel servers, Apache (in a reverse proxy configuration, plus
different users for each application to maximize security) is handled
by another script.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs