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

Discussion in 'Installation/Configuration' started by iNet Specialists, Mar 8, 2017.

  1. iNet Specialists

    iNet Specialists New Member

    This is a snapshot from one of two CentOS 7.3.1611 VMs with ISPConfig 3.1.2
  2. Jesse Norell

    Jesse Norell Well-Known Member Staff Member Howtoforge Staff

    No, the cron jobs run and exit, they should not keep running. Individual websites can setup custom cron jobs though, and those could probably run for a while if they're buggy, poorly written or intentionally doing something like that; probably not forever, but for a while. The screenshot appears to be cgi processors for websites, not ISPConfig's cron jobs.
  3. iNet Specialists

    iNet Specialists New Member

    @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]
  4. Jesse Norell

    Jesse Norell Well-Known Member Staff Member Howtoforge Staff

    Indeed, that would be correct.
    A little looking around finds this:
    # grep FCGI /etc/apache2/sites-enabled/000-ispconfig.vhost
          FCGIWrapper /var/www/php-fcgi-scripts/ispconfig/.php-fcgi-starter .php
    And that /var/www/php-fcgi-scripts/ispconfig/.php-fcgi-starter appears to be a shell script which you could edit - though I don't know how to make your changes persistent through ispconfig upgrades (assuming that would be overwritten, I haven't actually tried).
  5. till

    till Super Moderator Staff Member ISPConfig Developer

    Search for the corresponding template in the ispconfig tar.gz file (install/tpl/ folder in the tar.gz) and put it to /usr/local/ispconfig/server/conf-custom/install/ and modify that copy to match your desired settings.
  6. iNet Specialists

    iNet Specialists New Member

    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
    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:
      DefaultMinClassProcessCount 1
      DefaultMaxClassProcessCount 3
      IPCCommTimeout 120
      IdleTimeout 360
      MaxRequestLen 8192000
    Then, I ran the update.php process from the command line.
    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.
    Last edited: Mar 15, 2017
  7. till

    till Super Moderator Staff Member ISPConfig Developer

    I guess the target path for the modified script has to be, but I havent tested it right now:


    instead of:


    Just in case your config get's overwritten during update, then please put it in the other location.

    The difference is:

    /usr/local/ispconfig/server/conf-custom/ contains templates that are used by the server script.
    /usr/local/ispconfig/server/conf-custom/install/ contains templates that overides the templates used by the updater.
  8. iNet Specialists

    iNet Specialists New Member

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

Share This Page