views:

514

answers:

2

I am setting up a Debian Etch server to host ruby and php applications with nginx. I have successfully configured inittab to start the php-cgi process on boot with the respawn action. After serving 1000 requests, the php-cgi worker processes die and are respawned by init. The inittab record looks like this:

50:23:respawn:/usr/local/bin/spawn-fcgi -n -a 127.0.0.1 -p 8000 -C 3 -u someuser -- /usr/bin/php-cgi

I initially wrote the process entry (everything after the 3rd colon) in a separate script (simply because it was long) and put that script name in the inittab record, but because the script would run its single line and die, the syslog was filled with errors like this:

May  7 20:20:50 sb init: Id "50" respawning too fast: disabled for 5 minutes

Thus, I got rid of the script file and just put the whole line in the inittab. Henceforth, no errors show up in the syslog.

Now I'm attempting the same with thin to serve a rails application. I can successfully start the thin server by running this command:

sudo thin -a 127.0.0.1 -e production -l /var/log/thin/thin.log -P /var/run/thin/thin.pid -c /path/to/rails/app -p 8010 -u someuser -g somegroup -s 2 -d start

It works apparently exactly the same whether I use the -d (daemonize) flag or not. Command line control comes immediately back (the processes have been daemonized) either way. If I put that whole command (minus the sudo and with absolute paths) into inittab, init complains (in syslog) that the process entry is too long, so I put the options into an exported environment variable in /etc/profile. Now I can successfully start the server with:

sudo thin $THIN_OPTIONS start

But when I put this in an inittab record with the respawn action

51:23:respawn:/usr/local/bin/thin $THIN_OPTIONS start

the logs clearly indicate that the environment variable is not visible to init; it's as though the command were simply "thin start."

How can I shorten the inittab process entry? Is there another file than /etc/profile where I could set the THIN_OPTIONS environment variable? My earlier experience with php-cgi tells me I can't just put the whole command in a separate script.

A: 

init.d script

Use a script in

/etc/rc.d/init.d

and set the runlevel

Here are some examples with thin, ruby, apache

http://articles.slicehost.com/2009/4/17/centos-apache-rails-and-thin

http://blog.fiveruns.com/2008/9/24/rails-automation-at-slicehost

http://elwoodicious.com/2008/07/15/nginx-haproxy-thin-fastcgi-php5-load-balanced-rails-with-php-support/

Which provide example initscripts to use.

edit: Asker pointed out this will not allow respawning. I suggested forking in the init script and disowning the process so init doesn't hang (it might fork() the script itself, will check). And then creating an infinite loop that waits on the server process to die and restarts it.

edit2: It seems init will fork the script. Just a loop should do it.

Aiden Bell
Thanks -- one issue that this answer doesn't handle is respawning the thin server if/when it dies. A person would have to login and manually start it at that point, which we can already do. As far as I know only inittab allows for automatic respawning. If anyone knows a way to tell init to respawn init.d scripts, that would also solve my problem.
towynlin
Maybe fork off (sorry) in the init script into a loop that repeatedly starts the server, and then if the process dies, the loop restarts and the server does, ad infinitum.
Aiden Bell
After running for several days, the thin process has not died. This leads me to believe that thin works differently than either (1) the php-cgi process itself or (2) anything started with spawn-fcgi (I'm not sure which) -- inherently intended to die after serving a certain number of requests.Armed with this knowledge I now believe I don't need to worry about respawning, though Aiden's answer would do the job if I did need to make sure thin would respawn. I have created a very simple init.d script that simply calls either "thin start" or "thin stop" with the appropriate arguments.
towynlin
Good stuff! All the best with your developing!
Aiden Bell
+1  A: 

And why don't you call a wrapper who start thin whith your options?

start_thin.sh:
#!/bin/bash
/usr/local/bin/thin -a 127.0.0.1 -e production -l /var/log/thin/thin.log -P /var/run/thin/thin.pid -c /path/to/rails/app -p 8010 -u someuser -g somegroup -s 2 -d start

and then:
51:23:respawn:/usr/local/bin/start_thin

Vish