WARNING: Error while sending QUERY packet. PID=82827

Can you plase send a debug log file to support at backwpup dot com. After switsching to debug log in BackWPup > Settings > Tab: Log you must run the job again.

I hope i can than see where that ccames from.

?I have opend a support Thread on WordFence Security form. I hope that there can help.
?
?https://www.ads-software.com/support/topic/error-while-sending-query-packet-pid

Hello!

This might not be Wordfence.

I have exactly the sam problem but with DreamObjects Backups and it started with WordPress 4.5 – see here:

https://www.ads-software.com/support/topic/php-warning-82

@designxdevelop – Are you getting the error AFTER everything has run or at the same time as writing to the DB?

Than it was a coincidence that both have installed Wordfence.

I have a log file where i can see that the message comes many time after the Database backup and than every time the php script has restarte.

I don’t have Wordfence and for me the message comes also after the whole backup is completed with DreamObjects.

Two different backup plugins give the same error after WordPress 4.5.

I also do not have Wordfence, but get the same problem when running a backup using plugin BackWPup. Here’s what I got for my last backup on April 22:
[22-Apr-2016 03:37:19] 1. Trying to create backup archive …
[22-Apr-2016 03:37:19] Compressing files as ZipArchive. Please be patient, this may take a moment.
[22-Apr-2016 03:42:00] WARNING: Error while sending QUERY packet. PID=593659
[22-Apr-2016 03:48:47] WARNING: Error while sending QUERY packet. PID=593659
[22-Apr-2016 03:54:11] WARNING: Job restarts due to inactivity for more than 5 minutes.
[22-Apr-2016 03:54:12] 2. Trying to create backup archive …
[22-Apr-2016 04:02:51] WARNING: Error while sending QUERY packet. PID=593659
[22-Apr-2016 04:04:53] WARNING: Error while sending QUERY packet. PID=607805
[22-Apr-2016 04:13:31] WARNING: Job restarts due to inactivity for more than 5 minutes.
[22-Apr-2016 04:13:32] 3. Trying to create backup archive …
[22-Apr-2016 04:21:55] WARNING: Job restarts due to inactivity for more than 5 minutes.
[22-Apr-2016 04:21:56] ERROR: Step aborted: too many attempts!

Everything I see points to Max Packets ( https://dev.mysql.com/doc/refman/5.7/en/packet-too-large.html ) which is just plain weird based on WHEN it’s happening for DreamObjects at least. There are two DB calls – one to dump the DB and one to write to the log.

BackWPup has one own DB connection for the dump and the WordPress default. BackWPup logs to file and not to database.

Thanks Mika for the hint.

This problem seems to somewhat similar to a previous WordPress problem:
https://www.ads-software.com/support/topic/php-warning-error-while-sending-query-packet

but that error contained a bit more information:
[22-Jul-2013 15:10:13 UTC] PHP Warning: Error while sending QUERY packet. PID=14707 in …wp-content/plugins/wp-db-driver/drivers/pdo_mysql.php on line 109

The problem originator, J.D. Grimes, and the plugin author, Marko Heijnen, seem to conclude the problem is due to a “database connection timeout interval in WordPress, like just setting a constant in wp-config.php. E.g.: define( ‘WP_DB_TIMEOUT’, 300 );”
The plugin author dismisses the problem like this:
“Having this issues with MySQL would seem like a misconfiguration in MySQL …
So fixing it on the MySQL end seems the best place.”
But that confuses me a bit, since wp-config.php is a WordPress specific file, not a general MySQL file. (But later on at a different website I read that it may be that either the max_allowed_packet or wait_timeout MySQL values thatmay cause the “Error while sending QUERY packet” error. See
https://stackoverflow.com/questions/30753674/error-while-sending-query-packet.)

I’ve heard of the wp-config.php file before, but am unsure of where it is at. Doing a search I found:
https://www.wpbeginner.com/beginners-guide/how-to-edit-wp-config-php-file-in-wordpress/
This website warns that you better do a backup before touching this file, whichI cannot do due to BackWPup failing. Yet increasing the value of WP_DB_TIMEOUT in wp-config.php certainly seems safe enough. (This website warns: “The wp-config.php file
is so crucial to a WordPress site that a tiny mistake will make your site inaccessible.”)

So, should I try changing WP_DB_TIMEOUT in wp-config.php file to try to fix this problem? Is that really the correct thing to try?

If that doesn’t work, should I try to muck with either the max_allowed_packet or wait_timeout MySQL values?

(By the way, BackWPup used to work for me. Something seems to have changed.)

(But before I try any of these things, I will try running my BackWPup again tonight. My site is trinityvcf.org.)

“Having this issues with MySQL would seem like a misconfiguration in MySQL …
So fixing it on the MySQL end seems the best place.”
But that confuses me a bit, since wp-config.php is a WordPress specific file, not a general MySQL file.

WP is overriding the default SQL configuration, is what’s going on there.

Maybe try this code out to see what happens. If someone is allowed to change the Global variables then this temporarily changes these DB Variable Values until the next time the server is rebooted. Worth checking it out anyway.

/*
Notes:
execute the function twice to see if the variable values are changed or not.
I did not bother with creating additional foreach queries for before and after.
If you exceed either the minimum or maximum values the Min|Max value will be used instead of your value.

integer is in bytes: 1024 = 1KB | 1073741824 = 1GB

max_allowed_packet
Permitted Values Type integer
Default	4194304
Min Value 1024
Max Value 1073741824

integer is in seconds: 28800 = 480 minutes | 31536000 = 525600 minutes = 8760 hours
wait_timeout
Permitted Values (Windows) Type integer
Default	28800
Min Value 1
Max Value 2147483

Permitted Values (Other) Type integer
Default	28800
Min Value 1
Max Value 31536000
*/

function buckwheat_says_make_mo_bigger_max_allowed_packet_n_wait_timeout() {
global $wpdb;	

	$max_allowed_packet = 'max_allowed_packet';
	$wait_timeout = 'wait_timeout';
	$result = $wpdb->get_results( $wpdb->prepare( "SHOW SESSION VARIABLES WHERE (Variable_name = %s) OR (Variable_name = %s)", $max_allowed_packet, $wait_timeout ) );

	echo '<div class="update-nag">';
	echo '<strong>Execute the function twice to see if the values change or not</strong><br>';	

	foreach ( $result as $data ) {

		echo '<strong>'.$data->Variable_name.': </strong>'. $data->Value.'</strong><br>';	

		if ( $data->Variable_name == 'max_allowed_packet' ) {

			//$map_value = '4194304'; // default value
			$map_value = '1073741824'; // max value
			$map_results = $wpdb->query( $wpdb->prepare( "SET GLOBAL max_allowed_packet = %d;", $map_value ) );
		}	

		if ( $data->Variable_name == 'wait_timeout' ) {

			//$wt_value = '28800'; // default value
			//$wt_value = '2147483'; // max value Windows
			$wt_value = '31536000'; // max value other
			$wpdb->query( $wpdb->prepare( "SET GLOBAL wait_timeout = %d;", $wt_value ) );
		}
	}

	echo '</div>';
}

buckwheat_says_make_mo_bigger_max_allowed_packet_n_wait_timeout();

Oh and meant to mention some other testing things that I checked. I did do a before and after check directly in the WP Core code in /wp-includes/wp-db.php on line 1803 to see if WP was altering max_allowed_packets in any way. The before and after checking results were the same. Obviously the wp-db.php code does not have any code that is intended to do anything with or to max_allowed_packets so I was just looking for a logic flaw somewhere and none were found.

So since this is just an insignificant “after the fact” error that does not prevent a backup from being successful then one of these 2 things below is true.

1. The issue does have to do with a particular user’s MySQL (or other DB type) max_allowed_packet and wait_timeout variable values/settings. Executing the function in my previous post will confirm or eliminate this possibility if Max values are set and the same error is still being outputted.

2. There is a logic flaw in the MySQL (or other DB type) error checking code itself. Something like a “timing” issue of when the error check (or a secondary error check) is actually performed relative to the execution/processing of the Query (most likely). A very general example would look something like this below and the only relative point being made here is “when” the catch happens and not the error checking code itself. It could be something that has changed in WP 4.5 where a “timing” issue similar to this type of thing could occur (very unlikely). ie the order of function processing changed or something similar to that effect.

foreach ( $x as $y ) {
	try {
		if ( $y->something() ) {
			// whatever is being processed
		}
	} catch (RuntimeException $e) {}
}

I’ve just started using this plugin and have the same issue (though with a different PID).

The backup however appeared to complete correctly.

If I can send any logs or anything else to help fix it, I will.

Sorry for my terrible english…

Since 21th june I have the same problems like oldmankit with backups from two different Homepages from two differen Hosters.

I don’t use Wordfence I’m using iThemes Security, after deactivating iThemes Security the problem still exist.

Homepage 1
5 Backups with 5 different Errormessages (PID)

[21-Jun-2016 23:43:41] WARNUNG: Error while sending QUERY packet. PID=2598
[22-Jun-2016 00:03:34] WARNUNG: Error while sending QUERY packet. PID=28768
[22-Jun-2016 01:34:53] WARNUNG: Error while sending QUERY packet. PID=26925
[22-Jun-2016 01:58:19] WARNUNG: Error while sending QUERY packet. PID=23441
[22-Jun-2016 02:17:07] WARNUNG: Error while sending QUERY packet. PID=11798

Homepage 2
2 Backups with the same Errormessage

[22-Jun-2016 00:20:07] WARNUNG: mysqli_query(): MySQL server has gone away
[22-Jun-2016 00:20:07] WARNUNG: mysqli_query(): Error reading result set’s header

[22-Jun-2016 02:19:07] WARNUNG: mysqli_query(): MySQL server has gone away
[22-Jun-2016 02:19:07] WARNUNG: mysqli_query(): Error reading result set’s header

Greetings Frank