Re: mod_fcgid: can't apply process slot

On 6/9/25 12:36, Lars Noodén wrote:
> Hello,
> 
> I have a FastCGI script working with Apache2 on one system, but seem to 
> have missed something while trying to port it over to another system. On 
> the new system, the browser takes a long time before finally returning a 
> "503 Service Unavailable" message.
> 
> When that happens, the log file shows the following errors (indented 
> here for readability),
> 
>      . . .
>      [Mon Jun 09 08:43:34.566447 2025] [fcgid:warn] [pid
>      1910852:tid 1910852] [client xx.yy.zz.aa:61458]
>      mod_fcgid: can't apply process slot for
>      /var/www/example.org/fcgi/x_test-00.fcgi
> 
>      [Mon Jun 09 08:43:46.324188 2025] [fcgid:warn] [pid
>      1910900:tid 1910900] [client xx.yy.zz.aa:52592]
>      mod_fcgid: can't apply process slot for
>      /var/www/example.org/fcgi/x_test-00.fcgi
>      . . .
> 
> The script works fine on its own:
> 
>      $ sudo -u www-data REQUEST_METHOD="GET" \
>          /var/www/example.org/fcgi/test.fcgi
>      Content-Type: text/plain
> 
>      Hello, World! 0
> 
> I have the following in the Apache2 vhost for that site:
> 
>       . . .
>          ScriptAlias /search/query /var/www/example.org/fcgi/test.fcgi
>          <Directory /var/www/example.org/fcgi>
>                  Options +ExecCGI
>                  AddHandler fcgid-script .fcgi
> 
>                  Order allow,deny
>                  Allow from all
>          </Directory>
>       . . .
> 
> I have looked at the following for ideas,
> 
>      https://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html
> 
> I've tried modifying /etc/apache2/mods-available/fcgid.conf to increase 
> FcgidMaxProcesses and FcgidMaxProcessesPerClass to various large 
> numbers, and then reloading, but to no effect.  That's probably barking 
> up the wrong tree, however.
> 
> What settings have I missed?
> 
> /Lars
> 
> ---
> 
> $ /usr/sbin/apache2ctl -v
> Server version: Apache/2.4.62 (Debian)
> Server built:   2024-10-04T15:21:08
> 
> $ /sbin/a2query -m | sort
> access_compat (enabled by maintainer script)
> alias (enabled by maintainer script)
> auth_basic (enabled by maintainer script)
> authn_core (enabled by maintainer script)
> authn_file (enabled by maintainer script)
> authz_core (enabled by maintainer script)
> authz_host (enabled by maintainer script)
> authz_user (enabled by maintainer script)
> autoindex (enabled by maintainer script)
> cache (enabled by site administrator)
> deflate (enabled by maintainer script)
> dir (enabled by maintainer script)
> env (enabled by maintainer script)
> evasive (enabled by maintainer script)
> fcgid (enabled by maintainer script)
> filter (enabled by maintainer script)
> headers (enabled by site administrator)
> include (enabled by site administrator)
> mime (enabled by maintainer script)
> mpm_prefork (enabled by maintainer script)
> negotiation (enabled by maintainer script)
> reqtimeout (enabled by maintainer script)
> rewrite (enabled by site administrator)
> setenvif (enabled by maintainer script)
> socache_shmcb (enabled by site administrator)
> ssl (enabled by site administrator)
> status (enabled by maintainer script)
> 
> $ lsb_release -rd
> No LSB modules are available.
> Description:    Debian GNU/Linux 12 (bookworm)
> Release:        12
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]

Thanks to those who read the first message.

After some adjustments, I started getting the following error instead 
which led to finding a work-around:

[Thu Jun 19 11:25:22.899742 2025] [fcgid:error] [pid 2824873:tid 
2824873] (13)Permission denied: mod_fcgid: couldn't bind unix domain 
socket /var/lib/apache2/fcgid/sock/2824873.59

It turns out that on this other system, Apache2 has a non-default user 
set for that (and another) vhost via the User directive.  A work-around 
seems to be to change the ownership of /var/lib/apache2/fcgid/sock/ from 
the default Apache2 user to the account specified by the User directive 
for that vhost.  This is not a permanent solution because there can be 
more vhosts each with custom User/Group directives, assuming the sockets 
directory persists across reboots.

The sockets directory seems to have been created by the package 
libapache2-mod-fcgid:

$ dpkg -S  /var/lib/apache2/fcgid/sock/
libapache2-mod-fcgid: /var/lib/apache2/fcgid/sock

Perhaps this quirk is a bug in Debian's package for Apache2's fcgi 
module in Debian because it is not reading the vhosts' User/Group 
settings.

In my case those User + Group directives have been set per-vhost in the 
individual vhosts' configuration files while /etc/apache2/envvars still 
contains the default.

$ grep -R  '^User ' /etc/apache2/sites-available/*.conf | wc -l
4

$ grep -R www-data /etc/apache2/
/etc/apache2/envvars:export APACHE_RUN_USER=www-data
/etc/apache2/envvars:export APACHE_RUN_GROUP=www-data

So the installer would have to look in more than just 
/etc/apache2/envvars and the three places which would have to be aware 
of vhost settings are in debian/libapache2-mod-fcgid.postinst, 
debian/rules, or debian/tests/perl.  I'll have to think on it.

Maybe FcgidIPCDir can be set on a per-vhost basis?

/Lars

PS.  Speaking of possible bugs, I notice that the mailing list appends 
the suffix .INVALID to my e-mail address, oddly.