How to fix mod_fcgid: can't apply process slot

Question

Recently, my server froze up, refusing to respond to requests. I was unable to connect via SSH, and finally, after some contact with my hosting provider, the server restarted and resumed working.

I checked the logs, and right at the time the server stopped responding, my logs show around 300 of the following error:

mod_fcgid: can't apply process slot for /dh/cgi-system/php80.cgi

A google search recommended modifying the fcgid settings. However, my site is hosted on a VPS and I don't have access to those settings myself. Another recommendation suggested switching from FastCGI to regular CGI. Can someone explain the ramifications of doing so, or provide alternate suggestions for how to fix the issue?

Answer 1

In general I'd recommend the existing Q&A material and other publis resources, to get into more knowledge, as it has multiple aspects which in the end are relevant on your VPS and environments and projects can differ a lot - if not the usage patterns of the PHP application.

Given the VPS is without superuser-level access, and the Apache Webserver in use, the key difference between CGI and FCGI is the process/execution model:

• CGI: Apache on a new request executes the PHP CGI binary in the "environment" of the request, the then running PHP handles the request, processes it (your PHP scripts) and the output of PHP then is taken from Apache to be send to the client. The PHP CGI binary process exits. [RFC 3875]

This means that per request a new PHP process on the operating system will be started. This is relatively expensive. But it allows you to configure more as non-root as for example you can specify the CGI binary and therefore all its configuration (IIRC even in .htaccess). Study the docs responsibly.

• FCGI: The Fast-CGI approach, you currently have. A PHP FCGI binary or process manager is started upfront, then on a new request, PHP executes "only" the script. That is it can be pre-loaded and is "waiting" for execution and then can faster handle a request as the overhead of starting a new request on each request is reduced. (This description is very likely incomplete and imprecise, but I hope it suffices to make the difference clear.) [FastCGI]

Now say you can't configure Apache by it's system configuration, in FCGI you can't control how many children are allowed and with which memory settings etc. . You could not even reload the process manager as the server needs to/sould control that, and you don't have access on that level.

There can always be different implementations and forms of control, therefore I can imagine that it is possible to control FCGI for PHP well enough on a well configured VPS without superuser-level access from a users perspective, but not every sysadmin is as brilliant as I was gratefully able to work with in the past, providing FCGI interface to PHP when it was not there yet around the beginnings of that protocol. FastCGI was really fast™ compared to CGI which was in use before.

---

[RFC 3875]: https://www.rfc-editor.org/rfc/rfc3875 The Common Gateway Interface (CGI) Version 1.1

[FastCGI]: https://www.mit.edu/~yandros/doc/specs/fcgi-spec.html FastCGI Specification; Mark R. Brown; Open Market, Inc.; Document Version: 1.0; 29 April 1996