Suspicious process running under user cpanelroundcube

Hi @martin MHC

I shall try to put your mind at rest

I believe that PHP-FPM is also used by cPanels own internal web server/PHP processes(which is a separate and distinct service to the Apache/PHP processes used by the clients), and as such, you don't have any control over it.

The message you are getting actually refers to the php-fpm process that roundcube is calling as a normal part of its PHP script execution. Your cPanel internal default PHP is 7.2 (I think since cPanel v76) and I believe it now uses php-fpm as the internal Handler instead of the php-cgi handler that the article you refer to states.

Lots of things, of course, that can influence this - connection speed, traffic bottlenecks, speed of clients hardware/software etc etc

The fact that you can't replicate it does indicate there is not anything terribly wrong. You might like to have a look at Tweak Settings >
Max cPanel process memory (Minimum: 768)
The maximum memory a cPanel process can use before it is killed off. This settings minimum value depends on the number of cPanel accounts on the system.

If you don't have a memory constraint, you could try allocating a little more to this setting, and see if it improves your clients experience any.

I really don't know why CSF/LFD insists in flagging all the PHP-FPM process as being a threat - although a malicious script could trigger an excessive use of the FPM resources.

You can safely add the following regex to your /etc/csf/csf.pignore file

Code:

pexe:/usr/local/cpanel/3rdparty/php/.*/sbin/php-fpm

which will stop the false notifications, irrespective what internal PHP version cPanel installs.

I hope this helps

 

The change may have been the action of upgrading WHM/cPanel to version 76 which installed the cPanel internal PHP version 7.2/PHP-FPM handler (I seem to remember cPanel used to use PHP5.6 and PHP-CGI in previous builds).

The false trigger of the LFD mail will only happen if the internal FPM process uses more time/resources than LFD is configured to look for. If a user suddenly changes from say pop to IMAP and/or starts having a significantly higher number of mails files to read, the FPM process would be strained and the LFD trigger may fire.

You might want to review what CSF/LFD settings you have that relate to the length of time a PHP script is permitted to run for before triggering a warning (PT_USERTIME), and/or what memory the process is permitted to use before warning (PT_USERMEM) - in fact; review all of the PT_ section carefully

***EDIT***

Have a look in your /etc/csf/csf.pignore file and look for an entry that looks anything like

Code:

exe:/usr/local/cpanel/3rdparty/php/56/bin/php-cgi

If you find an entry that looks anything like that, it may have been ignoring the processes under the old PHP/CGI already, and now you have a new PHP/FPM it is obviously not being blocked.