mod_fcgid warning in logs

Yeah right,

its me again. Well as soon as I have fixed something, I guess the next thing is just waiting for me. Well this is probably NOT a real Virtualmin issue but maybe somebody can help me solving it anyway.

I found mod_fcgid errors in my apache error.log:

[warn] (35)Resource temporarily unavailable: mod_fcgid: write data to fastcgi server error

They appear everytime when I try to upload files bigger than lets say 40KB thru PHP and therefor thru suexec and mod_fcgid. My browser is then just throwing an "External Server Error".

I installed the latest release mod_fcgid v2.2 but still no go!?

Does anybody have an idea how to solve this issue?

I added this to my global Apache2 config file:

<IfModule fcgid_module>
SharememPath /opt/local/apache2/logs/fcgid_shm
SocketPath /opt/local/apache2/logs/fcgid.sock
IPCCommTimeout 45
MaxProcessCount 12
MaxRequestsPerProcess 500
MaxRequestInMem 201002
MaxRequestLen 595038
DefaultMaxClassProcessCount 4
IdleTimeout 3600
BusyTimeout 3600
ProcessLifeTime 36000

Thanks in advance,

Maybe I should mention that the upload script runs under PHP4 which I chose as the default version for this virtual server.
I searched the net up and down, changed the config back and forth, trashed the mod and recompiled it, but still no luck. Somebody else reported the same error using files not bigger then 12KB. Seems mod_fcgid is a tricky beast, just like suexec. ;)<br><br>Post edited by: tony.p, at: 2007/08/18 23:53

Does nobody have an idea how I could solve this? I posted already a bug report on the website but no feedback so far. :[

Is there a possiblity for my to run mod_fastcgi instead of mod_fcgid for my PHP4 and PHP5 install? If so, what do I have to change in order to get this to work?


mod_fastcgi doesn’t work at all under suexec on Apache 2.x. I had nothing but trouble from it (it also had numerous other issues in our testing).

I’m not sure what to tell you…it’s not giving us any hassle here (we run with mod_fcgid under suexec configured exactly the same as Virtualmin configures it for you–eating our own dog food, of course!). It might be possible to make debug build or crank up logging in mod_fcgid which might give a clue.

Was the other user reporting the problem also using Max OS X?

Hi Joe,

thanks for letting me know. I filed another Bug report yesterday (on after testing again with a script FROM but it shows exactly the same behaviour as the scripts I wrote myself. It’s really odd… I have no clue if its a PHP or mod_fcgid issue and I don’t know how to solve it.

I know this much:
When starting Apache, mod_fcgid spawns exactly 5 processes for each vhost. Now, when using a simple upload script and submitting a file larger than 4-8KB all of those child processes are killed at once for the specific vhost the script was executed on. Therefor mod_fcgid is spitting out "[warn] (35)Resource temporarily unavailable: mod_fcgid: write data to fastcgi server error" and Apache throws a "500 Internal Server Error".

Could very well be that it behaves better running other cgi apps and beside this issue (wich is a big deal for me) I haven’t found any other problem so far.

The other user on the "mod_fcgid users" website that reported something like this was running a Linux distro I think. But according to some older bug reports on there were issues before and I think they never got taken care of properly. :frowning:


ps: I tried mod_fastcgi in the meantime already and I too can say it is nothing but troublesome and runs not smoothly at all.

Joe or Jamie,

could you have a look at this and tell me what you think?
This is the output of GDB on a php-cgi processes after I get whipped by Apache with an "500 Internal". Not sure how to troubleshoot it from here, maybe you could tell me…

The output is for latest PHP CVS [5.2.xxxx]:

[code:1]Attaching to program: `/usr/local/bin/php-cgi’, process 25912.
Reading symbols for shared libraries … done
0x9004eb97 in accept ()
(gdb) c

Program received signal SIGPIPE, Broken pipe.
0x9001029c in write ()
(gdb) bt
#0 0x9001029c in write ()
#1 0x002e79b3 in fcgi_flush (req=0xbfffdc00, close=1) at
#2 0x002e7a29 in fcgi_finish_request (req=0xbfffdc00) at
#3 0x002e825f in fcgi_accept_request (req=0xbfffdc00) at
#4 0x002ea880 in main (argc=1, argv=0xbffffdd0) at

Hey Tony,

I’m afraid, you’ve reached the end of the pier with regard to my knowledge, but you’re a champ for knowing how to get a backtrace. :wink:

This is pretty deep in the PHP code, and I’m not going to be much use in debugging PHP. You’ll probably need to take it up with the PHP folks–probably filing a bug at

Does this happen if you run the scripts as CGI instead of FCGI? That’d help narrow it down, anyway, and make it easier for the PHP folks to isolate and correct the problem. It may also hint at trouble in mod_fcgid, instead of PHP. Hard to tell (I don’t think all of the symbol names are available in this backtrace, as it’s not really very informative, but even with all of the symbols I’d probably be useless on debugging it).

Hi Joe,

sorry was busy with some other crap here and had no time. And well its of course very frustrating. A bug report was filed at and also at the mod_fcgid site, but so far nobody wants to help which makes it even more frustrating for me. I am stuck with this now and can not continue with my server setup if this is not running properly. :frowning:

Anyway, this happens when running scripts in FCGI mode. I have not tried CGI!? How would I run this in CGI and still be able to use SuExec for propper permission handling? I have tried mod_php5 which works just fine BUT of course WITHOUT the permission handling which makes it useless for my vhosts.


CGI is also subject to suexec. It works exactly the same way, only with one fewer process in between your script and the webserver. Just use Virtualmin to switch over the "PHP script execution mode" in Website options and save it. Virtualmin should create cgi wrappers and set it all up for you.

This will do two things for you:

Tell you if the problem is in fcgid or the fastcgi support in PHP (you can’t be sure which since this removes both from the equation) or if it is in some other part of PHP.

Possibly allow you to workaround the problem and get launched. CGI isn’t as fast as fcgid, but it is as secure. And, many shared hosting providers ONLY offer CGI script execution, so it’s being used all over the world by millions of sites…slowly, but it gets the job done. And most sites aren’t seeing enough load to feel the pain.


man I could kiss you!! It works… well, without mod_fcgi, but at least it does work. So it really must be fcgid then!? You don’t think PHP is handling the regular cgi stuff differently as to parsing it thru fcgid?!

Btw… I think that my problem(s) with mod_fcgid could be because of OSX or the hardware (Xserve 64bit Xeon Dual) I am using here. I compiled pretty much all versions of it from source without any errors. hmm… well I will keep buggin those guys over at their sourceforge project page until this is finally solved. :smiley: :wink:

BIG thanks to you Joe, now I can finally continue with my setup…


man I could kiss you!!

A pat on the back is more customary where I’m from, but hey, when in Rome. :wink:

well, without mod_fcgi, but at least it does work. So it really must be fcgid then!? You don't think PHP is handling the regular cgi stuff differently as to parsing it thru fcgid?!

No, FastCGI is a different path in PHP, as well. It is transparent to PHP users, but if you were writing a Perl, Ruby, or Python script, you actually have to plan for FastCGI protocol use. Basically, the fcgi protocol is a sort of magic client/server protocol for talking between the webserver (mod_fcgid or mod_fastcgi) and the application (PHP in this case), and both sides have to speak that protocol. Customarily, the application will then spawn long-running daemons under the control of the webserver–which is why it takes special coding techniques in everything other than PHP, because the code can’t be counted on to exit and start clean, as it does in CGI. It is more of a loop.

So, it could still be a bug in PHP, or it could be a bug in mod_fcgid on Mac OS X. If I were a betting man, I’d guess it’s mod_fcgid rather than PHP, but we can’t be sure of that. The actual crash, if I recall correctly returned some references to PHP libraries…so it could very well be PHP. Impossible to know with the data we have, I think (or at least with the data we have and the knowledge that I have of the fcgid and php codebases).

well I will keep buggin those guys over at their sourceforge project page until this is finally solved.

Keep it friendly. We need them more than they need us lowly users of their software. :wink:

If the problem is still around when we actually get Virtualmin supported officially on Mac OS X I’ll take the time to try to get it straightened out (I don’t have a Mac, and I’ve got a todo list as long as my arm, in a small font, so it’s not gonna be in the next few weeks, though). But, maybe as the Mac gets more popular as a server platform, and mod_fcgid becomes more popular (mod_fastcgi is still the most popular FastCGI implementation, but it’s broken for suexec), someone with more experience with the code will run into the problem and get it worked out.