wp-toolkit generates "Failed to reset cache for the instance #42" errors

[burnley]

OS: CentOS Linux 7.7.1908 (Core)
‬Product: Plesk Onyx Version 17.8.11 Update #68, last updated on Sept 18, 2019 10:22 PM

We've had these reports from some of our clients, they're receiving emails that look like this:
---CUT HERE---
Subject: <plesk Application Updates.

Updates were not installed for the following items:

1. Website "/staging" (domain1.com.au): Failed to reset cache
for the instance #5

2. Website "/staging" (domain2.net.au): Failed to reset cache
for the instance #27

3. Website "/httpdocs" (domain3.com): Failed to reset cache for
the instance #30
---CUT HERE---

And in /var/log/plesk/panel.log we see:
---CUT HERE---
[2019-10-26 05:47:47.048] ERR [extension/wp-toolkit] An error occurred while executing WP-CLI command for instance: WordPress instance #5 ('/staging')
[2019-10-26 05:47:47.605] ERR [util_exec] proc_close() failed ['/usr/local/psa/admin/bin/filemng' 'dom1user' 'exec' '/var/www/vhosts/domain1.com.au/staging' 'timeout' '60' '/opt/plesk/php/5.3/bin/php' '-d' 'safe_mode=off' '-d' 'd
isplay_errors=off' '-d' 'opcache.enable_cli=off' '-d' 'open_basedir=' '-d' 'error_reporting=341' '-d' 'max_execution_time=60' '-c' '/var/www/vhosts/system/staging.domain1.com.au/etc/php.ini' '/usr/local/psa/admin/plib/modules/wp-toolkit/vendor/wp-cli/wp-cli/php/boot-fs.php' '--path=/var/www/vhosts/domain1.com.au/staging' '--no-color' 'config-settings' 'get' '--params=DB_CHARSET,DB_NAME,DB_USER,DB_PASSWORD,DB_HOST,DOMAIN_CURRENT_SITE,PATH_CURRENT_SITE,MULTI
SITE,SUBDOMAIN_INSTALL,WP_AUTO_UPDATE_CORE,WPCACHEHOME,WP_DEBUG,WP_DEBUG_LOG,WP_DEBUG_DISPLAY,SCRIPT_DEBUG,SAVEQUERIES,WP_AUTO_UPDATE_CORE,WP_HOME,WP_SITEURL,CONCATENATE_SCRIPTS,DISALLOW_FILE_EDIT,WP_CACHE_KEY_SALT' '--format=json'] with exit code [18]
[2019-10-26 05:47:47.611] ERR [1] '/usr/local/psa/admin/bin/filemng' 'dom1user' 'exec' '/var/www/vhosts/domain1.com.au/staging' 'timeout' '60' '/opt/plesk/php/5.3/bin/php' '-d' 'safe_mode=off' '-d' 'display_errors=off' '-d' 'opcache.enable_cli=off' '-d' 'open_basedir=' '-d' 'error_reporting=341' '-d' 'max_execution_time=60' '-c' '/var/www/vhosts/system/staging.domain1.com.au/etc/php.ini' '/usr/local/psa/admin/plib/modules/wp-toolkit/vendor/wp-cli/wp-cli/php/boot-fs.php' '--path=/var/www/vhosts/domain1.com.au/staging' '--no-color' 'config-settings' 'get' '--params=DB_CHARSET,DB_NAME,DB_USER,DB_PASSWORD,DB_HOST,DOMAIN_CURRENT_SITE,PATH_CURRENT_SITE,MULTISITE,SUBDOMAIN_INSTALL,WP_AUTO_UPDATE_CORE,WPCACHEHOME,WP_DEBUG,WP_DEBUG_LOG,WP_DEBUG_DISPLAY,SCRIPT_DEBUG,SAVEQUERIES,WP_AUTO_UPDATE_CORE,WP_HOME,WP_SITEURL,CONCATENATE_SCRIPTS,DISALLOW_FILE_EDIT,WP_CACHE_KEY_SALT' '--format=json' failed with code 18.

stdout:


stderr:
WP-CLI needs WordPress 3.7 or later to work properly. The version currently installed is 2.8.4.
Try running `wp core download --force`.
{"err_code":10002,"err_message":"WP-CLI needs WordPress 3.7 or later to work properly. The version currently installed is 2.8.4.\nTry running `wp core download --force`."}

[2019-10-26 05:47:49.447] ERR [extension/wp-toolkit] An error occurred while executing WP-CLI command for instance: WordPress instance #5 ('/staging')
[2019-10-26 05:47:49.452] ERR [extension/wp-toolkit] Failed to reset cache for the instance #5, reason: To register and manage this WordPress website in WordPress Toolkit, please manually upgrade it to version 3.7 or later.
[2019-10-26 05:47:49.485] ERR [extension/wp-toolkit] Unable to process auto updates for WordPress instance #5 ('/staging'): Failed to reset cache for the instance #5
---CUT HERE---

How can we disable these notifications?

 

[IgorG]

What version of WP Toolkit is installed on your server? Make sure that it is updated to latest version.

 

[burnley]

WordPress Toolkit
Version 4.3.4-2520

All installed extensions are up-to-date
No updates are available for any of the installed extensions. You have the latest versions of extensions installed.

 

[wilbert]

Same issue here, every day i get an email with a lot of sites showing
Failed to reset cache for the instance
The sites are all updated?
How to get lost with the (falce) notifictaions

 

[Kaspar]

I have the same issue. Any one found a solution for this?

1. Website "/httpdocs/staging" (domain.com): Failed to reset cache for the instance #37: filemng: Failed to change directory to /var/www/vhosts/domain.com/httpdocs/staging: No such file or directory

System error 2: No such file or directory
filemng: Failed to change directory to /var/www/vhosts/domain.com/httpdocs/staging: No such file or directory

System error 2: No such file or directory

 

[Pan_Duke]

Hi all, it's been 5 days now that i stated getting this message. But in my case it is much worse since everytime the check runs (once per day) my main composer plugin is deactivated. I use Tagdiv's Newspaper theme and Tagdiv composer deactivates, turning the site into an anusable condition every mornig. How can i fix this?

Updates were not installed for the following items:

1. Website "mydomain" (https://mydomain.net): Failed to reset cache for the instance #4: An error has occurred when decoding JSON: Decoding failed: Syntax error

2. Website "mydomain" (https://staging.mydomain.net): Failed to reset cache for the instance #5: An error has occurred when decoding JSON: Decoding failed: Syntax error

I tried disabling nginx cache and even the cache plugin (WP total cache, which i find stupid, but in any case) and still the same. Every morning i have to manually activatthe composer plugin.

 

[LTUser]

I have the same issue. Any one found a solution for this?

Same here, latest Pleskversion and Updates...

Failed to reset cache for the instance #4: An error has occurred when decoding JSON: Decoding failed: Syntax error

 

[frg62]

Ditto here:

Failed to reset cache for the instance #4: An error has occurred when decoding JSON: Decoding failed: Syntax error

For several WP websites.

And this began AFTER WP Toolkit was updated to version 4.7.1-3439, because my servers that have not yet updated (4.7.0-3429), do NOT send me such messages!

 

[Josch]

Same here since April, 20th:

Failed to reset cache for the instance #24: Fehler bei der Dekodierung von JSON: Decoding failed: Syntax error

It's really annoying

 

[Clemens]

Same here, lots of clients are complaining about these messages.

Failed to reset cache for the instance #218: Failed to parse wp-config.php: Uncaught TypeError: Argument 1 passed to WP_CLI\Runner::WP_CLI\{closure}() must be an instance of Exception, instance of Error given in /usr/local/psa/admin/plib/modules/wp-toolkit/vendor/wp-cli/wp-cli/php/WP_CLI/Runner.php:1685
Stack trace:
#0 [internal function]: WP_CLI\Runner->WP_CLI\{closure}(Object(Error))
#1 {main}
thrown on line 1685

--
Failed to reset cache for the instance #220: filemng: Failed to change directory to /var/www/vhosts/[anonymized]: No such file or directory

--
System error 2: No such file or directory

 

[malfunction]

Yes, we're drowning in these 'notifications' too. every four hours from every server. Warnings look to be related to WP installations that no longer exist.

 

[wolle]

same here since 2 weeks:

Failed to reset cache for the instance #2: An error has occurred when decoding JSON: Decoding failed: Syntax error​

 

[MicaT]

Hi everybody,

Same for me, I have the same kind of issue. Though that was from a bad "de-installation" of a backup plugin. Then I removed manually the folder related to it. Re-installed the plugin.
Does anybody knows how to reset manually that cache ?

Les mises à jour des éléments suivants n'ont pas installées :

1. Site Web "/Backup manuelle/04_Mars_2019" (john-link.com) : Failed to reset cache for the instance #13: Impossible de lire le fichier de configuration WordPress.

 

[IgorG]

1. Site Web "/Backup manuelle/04_Mars_2019" (john-link.com) : Failed to reset cache for the instance #13: Impossible de lire le fichier de configuration WordPress.

Usually, this is caused by missing WordPress website files. Go to Domains > example.com > File manager. Put all WordPress website files into the domain document root

 

[LTUser]

Fixed here...

Same here, latest Pleskversion and Updates...

Failed to reset cache for the instance #4: An error has occurred when decoding JSON: Decoding failed: Syntax error

Ok, I found the cause of this error.
One of your plugins is faulty, even if it seems to work.
First: Make sure all plugins are up to date ... If so,
inspect the error log of the php_fpm version used.

[13-May-2020 16:01:20] WARNING: [pool mydomain.tld] child 23715 said into stderr: "PHP message: PHP Warning: session_start(): Cannot start session when headers already sent in /var/www/vhosts/mydomain.tld/httpdocs/wp-content/plugins/uber-media/uber-media.php on line 45"

If you cannot do this, you must deactivate all plug-ins and activate them individually. Check for updates after each addon activation in Plesk. If the error occurs again, you have found the (first?) Faulty plugin.

Hth.

 

[Clemens]

As @LTUser already stated, it could be a faulty plugin. In my situation it was caused by a bug in wp-config.php, site worked fine, but WP toolkit crashed on the Warning.

Finding the cause
I found that bug by editing /usr/local/psa/admin/plib/modules/wp-toolkit/vendor/wp-cli/wp-cli/php/WP_CLI/Runner.php and changing line 1685 to

set_exception_handler( function( $exception ) {

It doesn't fix the problem, but what it does is show the original error/warning that caused WP toolkit to crash.


Manually clearing cache
You can use wp-toolkit to manually clear cache of an instance.

// Get a list of all WP instances registered to wp-toolkit
plesk ext wp-toolkit --list

// Clear cache of an instance, use the intance-id found in the previous list
plesk ext wp-toolkit --clear-cache -instance-id [instance-id]

Reset cache for all instances
I wrote a little script to reset cache for all registered WP instances. Wait for a crash/warning, fix the WP instance and re-run the script. Put it in a file wpfix.sh and chmod 755 and execute.

plesk ext wp-toolkit --list | awk '{ print $1 }' |&
while read -p first second ; do
  if [[ $second != 'ID' ]]
  then
    echo "Clearing cache for $second"
    plesk ext wp-toolkit --clear-cache -instance-id $second
    echo ""
  fi;
done

Fix for removed WP installations

After removing a WordPress domain in Plesk, WordPress Toolkit starts to show error: Can not find domain by id

Applicable to: Plesk for Linux Plesk for Windows Symptoms After removing a sub-domain with WordPress instance, the following error message appears in Plesk/WordPress Toolkit (ID in the error mes...

support.plesk.com

In my situation this fixed the problem for one day. The next day the remove WP installations were registered again. I had to manually cleanup the wp-confg in last_nginx.conf and last_httpd.conf. Look for "extension wp-toolkit begin" and cleanup the config referencing the removed WP installs.

 

[XTech]

I am having the same issue while trying to restore from a backup, I know it is a plugin causing this issue. I disabled that plugin but tried to restore it again and it still gave me the same error. This might be because the plugin already exists in the backup.

Failed to restore the extension wp-toolkit: Failed to reset cache for the instance #1: An error has occurred when decoding JSON: Decoding failed: Syntax error

I would appreciate any help on this.

 

[squaladesign]

I'm having the same problem

 

[squaladesign]

I check the log and this is the error:

Site data was not refreshed due to the following error: Failed to reset cache for the instance #30: An error has occurred when decoding JSON: Decoding failed: Syntax error. Cache tags: ["action-log-existence","main-information","ip","ssl-statuses","remote-agent-instance","cloud-linux-cagefs","cpanel-links","admin-credentials","admin-login-link","php","plugins","themes","config","nginx-caching","maintenance-mode","table-prefix","force-updates","security-measures","protected-dir","screenshot","virtual-patches","available-minor-update-version"]

 

[Peter Debik]

The "Failed to reset cache for the instance ... when decoding JSON" is normally caused by a WP theme that does not follow WP guidelines how a theme must be built. It's not a bug of Plesk, but of the theme.