[SOLVED] Are the ISPConfig FCGI processess supposed to be persistent?

This is a snapshot from one of two CentOS 7.3.1611 VMs with ISPConfig 3.1.2

 

@Jesse Norell
Thanks for confirming that, so I seem to have answered my own question.

The fastCGI instances that I am seeing are the ones spawned for the ISPConfig vhost. (magic_quotes_gpc gave me the clue I needed)

The cron processes do spawn and then close down as children of /usr/sbin/crond as they should.

While I understand web sites can run similar processes, these are running as the ispconfig user. A website would be running as one of the 'webnn' users and have a phpopenbasedir limitation. These are definitely ISPConfig related... Now I need to make some adjustments so there are only a couple of these running instead of 6 (too wasteful for a small VM with Control Panel access limited to just me)

ispconf+ 1037 0.0 1.9 281580 10088 ? S 10:42 0:04 /usr/bin/php-cgi -d disable_classes= -d disable_functions= -d magic_quotes_gpc=off -d open_basedir= -d session.save_path=/usr/local/ispconfig/interface/temp

(For comparison) This is a REGULAR website using fastCGI...
web20 11288 0.3 1.9 260480 15504 ? S 15:37 0:02 /usr/bin/php-cgi -d open_basedir=/var/www/clients/client16/web20/web:/var/www/clients/client16/web20/private:/var/www/clients/client16/web20/tmp:/var/www/DOMAIN.TLD/web:/srv/www/DOMAIN.TLD/web:/usr/share/php5:/usr/share/php:/tmp -d upload_tmp_dir=/var/www/clients/client16/web20/tmp -d session.save_path=/var/www/clients/client16/web20/tmp -d sendmail_path=/usr/sbin/sendmail -t -i [email protected]

 

Great hints! This is solved... Thanks for the help!
The how for anyone else interested:
This server is purposed for light web hosting and development and only uses ISPConfig to make configuration easier. The rest of the time, it is intended to be used for FTP, DB Management, Subversion, Bug Tracking, etc. (all internal, only for a few users). Therefore, when ISPConfig is NOT needed, it can literally just go away (it will come back on the first request).
I found the file: ispconfig3_install/install/tpl/apache_ispconfig.vhost.master (thanks @till)
Copied to /usr/local/ispconfig/server/conf-custom/install/apache_ispconfig.vhost.master

Code:

cp -a apache_ispconfig.vhost.master /usr/local/ispconfig/server/conf-custom/install/apache_ispconfig.vhost.master

Then added/modified these lines in the <IfModule mod_fcgid.c> section:

Code:

  DefaultMinClassProcessCount 1
  DefaultMaxClassProcessCount 3
  IPCCommTimeout 120
  IdleTimeout 360
  MaxRequestLen 8192000

Then, I ran the update.php process from the command line.
Notes:

1. For reference: https://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html
2. It is noteworthy to mention that these settings are applicable to each VirtualHost container.
3. FCGI processes are intended to run in memory as configured to reduce the time it takes to continuously load the code from the filesystem. However, this is only really helpful if the request is triggered on the same URL, like a CMS. Each URL invoked will spawn a seperate FCGI process which will take its own memory using the specified parameters for time and resources. (Read URL as /directory/index.php) So "/login/index.php" is not handled by the same process as "/index.php" unless the MaxClassProcessCount has been reached.
   
4. IPCCommTimeout was 7200 while the default is 40. I am not sure if there is a historical reason, but 2 hours seems excessive to wait for "The FastCGI application" to "begin generating the response".
5. MaxRequestLen was 15728640 (15MB) while the default is 131072 (128K). Again, not sure of any historical reason, but the maximum "request" size really shouldn't be any larger than the PHP maximum upload size.
6. IPCCommTimeout and IdleTimeout seem to be "additive" when determining how long it takes for the spawned FCGI processes to die off. In this case, it took about 9 minutes (480 seconds) for a set of FCGI processes to clear out of memory after the ISPConfig interface was logged out. However, as long as the "login" screen was open, at least one would live on.
   
7. DefaultMaxClassProcessCount of 3 is about how many FCGI processes were started by default. However, with a DefaultMinClassProcessCount of 1 set, when using the ISPConfig interface for longer than 9 minutes, the number of processes drops with no bad effects to response time at all. I suspect that if forced to, the ISPConfig interface could be run by a single FCGI process without any noticeable effects, but I haven't tested it.

 

@till
You are right and that is what I did, I corrected my typo above. Thanks again.