I’ve found the answer to my shared hosting prayers, in the form of FCGI_Watch, which provides a way to manage the FCGI processes on a shared server. I’ve got several Rails apps running on a shared account. The hosting setup is nice in that I can have multiple domains and rails apps on the same account, but as those who are in this situation know, dealing with FCGI processes is a real pain. When you have multiple apps, you will likely have quite a few fcgi processes running. If your need to reload the app, you can shut them all down, but that will, uh…shut them all down, which means each app will need to restart. Not the best idea for apps in produciton use. It’s also a much better option than script/process/reaper. Here’s the overview from Al Evans, who wrote it:
HOW DOES fcgi_watch SOLVE THESE PROBLEMS?
fcgi_watch finds and parses the fastcgi.crash.log in the
/log directory. It makes a list of processes that should be running, then cross-checks it against the output of ps to find all the FCGI processes that are actually running for a specified application. Only then does it perform the specified action. BUT THAT’S NOT ALL!
Managing FastCGI processes on a shared server is sometimes problematical. You have little control over the web server used, over
its configuration, or over the activities of other users. Your dispatchers might get swapped out and become “unresponsive”, causing the server to start new ones. After a day or so, “ps aux” might show eight or ten copies of dispatch.fcgi — more, if you have multiple applications — and you have no way of knowing which ones of them can be safely killed.fcgi_watch provides an “expire” action, in addition to the actions provided by reaper. fcgi_watch keeps track of the ages of instances of dispatch.fcgi, and can “expire” processes older than a given number of hours. You can also set a maximum number of FCGI dispatchers that you want to allow for a given application. “fcgi_watch expire” will terminate the extras — gracefully, if possible.