@madpilot makes

Using fcgid instead of fastcgi with Ruby on Rails

I have fallen victim to the fastcgi zombie process issue. It would seem that there is a problem with FastCGI running under apache2, where many zombie processes can not be killed, which eventually fills up the process table, slowing down the server. My guess is that is using up all of the sockets, thus stopping any other processes from taking connections (THis is speculation as I haven’t really investigated fully)

Any way – after a quick google, I found that other people have been successfully using the fcgid module, which is a binary compatible replacement for mod_fastcgi. Generic instructions can be found on this blog – however, the following instructions are suitable for Gentoo – it also allows you to use the .htaccess file, giving a finer site control:

1. emerge mod_fcgid (I used the ACCEPT_KEYWORDS=”~x86″ to get the latest version)

2. edit /etc/conf.d/apache – add the flag -D FCGID

3. modify the virtual host in the apache.conf file to include:

Options ExecCGI


DefaultInitEnv RAILS_ENV production (For production mode obviously)

4. modify /etc/apache2/modules/20_mod_fcgid.conf to include:

IPCCommTimeout 40
IPCConnectTimeout 10

(I put it immediately after the LoadModule directive)

5. modify the AddHandler fastcgi-script .fcgi line in [Rails_app_root]/public/.htaccess to read:

AddHandler fcgid-script .fcgi

6. Restart Apache.

I’ll keep you posted on whether it fixes the problem :)


  1. Do not use .htaccess files. They are slow. They increase the risk of various security issues.

    They are not required to get "a finer site control".

    If you have access to the httpd.conf, or an included file, you should ALWAYS use this over .htaccess files. Just put any directives that you would of put inside the .htaccess file, into a Directory block:

    AddHandler fcgid-script .fcgi

    This gives you more control that any .htacces file, since you can also do various regular expressions for matching paths. There are also some commands that only work form the main config files.
  2. Thanks for the comments Paul.

    Mind you the info is still helpful for those that can't 

  3. Thank you very much.

    I solved my problem.

    I wrote this solution in japanese.
  4. Sorry for dragging this old thread up with a comment, but how's the progress been going since January?

    I'm considering this and wanted to know how it all panned out. I'm running FreeBSD with Apache 1.3.x on my PHP site and, for the new RoR version I'm thinking of either running Apache 2.2 with mod_fcgi or proxying to Lighty for the site using Apache 2.2's proxy balancer.

    I would prefer to stick with Apache and mod_fcgi, as if Apache or anyone actually sorts all this out eventually, it will be easier for me to just upgrade my Apache and take advantage of that rather than stop proxying everything.

    P.S. How's the 'one-off' hit I've been reading about, i.e. the short delay for the first request. Is there absolutely no way whatsoever to overcome this, not even with some cronjob or something?? Thanks for any advice!
  5. Seems to be working a treat. I hasn't crashed and the processes are behaving themselves.

    The simplest way of overcoming the "one-hit" issue is to just browse to the website after you restart the process. All depends on how often you reboot you process :)
  6. Thanks a lot for the info - good to hear it's doing well!

    Just to clarify, from my reading, I gathered that the mod_fcgi process dies after some period X after inactivity, meaning that the next user will also have the one-hit delay.

    - So, after manual restarts I can just visit the site and that's fine for a while.

    - For automatic reboots that occur in my absence for whatever reason, I guess I can get the startup configuration files to just load some small public-facing page to get the process running too.

    - The only sticking point is a period of inactivity while the server is just sitting there. This seems too simple to be true, but if I set up a cron job to load some_small_file.php every X minutes, then it should start the process then as well.... right?
  7. Auto accessing the site via a crontab will do it. if you have wget on your system and cronjob that calls the front page should do it - heck, you could call a page that doesn't exist and it would probably still work :)

Leave a comment