php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #49761 Error while sending CHANGE_USER packet
Submitted: 2009-10-03 17:43 UTC Modified: 2009-10-15 20:49 UTC
From: oliviapurvis at yahoo dot com Assigned: uw (profile)
Status: Closed Package: MySQLi related
PHP Version: 5.3.0 OS: CentOS 5.3
Private report: No CVE-ID: None
 [2009-10-03 17:43 UTC] oliviapurvis at yahoo dot com
Description:
------------
I'm currently using Mysqli (mysqlnd) with persistent connection. When checking the apache error log file I get lots of this warning:

[Thu Oct 01 00:38:38 2009] [error] [client 122.122.122.122] PHP Warning:  Error while sending CHANGE_USER packet. PID=18133 in /home/mysite/myscript.php on line 10

Line 10 of the script is:
$db=new mysqli('p:localhost','user','pass','mydb',3306);

The warning is not generated on every request to the script. It occurs only once every few minutes.

Is this a bug?


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2009-10-03 17:48 UTC] oliviapurvis at yahoo dot com
By the way, the script runs without warning if not using persistent connection.

Also, when using persistent connection, the script works fine (as intended) even though there is a warning in the log file.
 [2009-10-03 18:41 UTC] uw@php.net
No it is not a bug, 98% quite sure about that.

COM_CHANGE_USER is a re-authentication command send from mysqlnd to the MySQL server. COM_CHANGE_USER is there to check that the user who wants to use the persistent connection is a) still allowed to connect to MySQL and b) it resets all session related data (reset user variables, close open transactions and so on - the MySQL manual has details on it).

ext/mysqli @ mysqlnd does send a COM_CHANGE_USER unlike ext/mysql. ext/mysql does not properly reset persistent connections, ext/mysqli does. All ext/mysql does is send a ping to check if the connection is still alive. If you want the ext/mysql behaviour, recompile PHP with -DMYSQLI_NO_CHANGE_USER_ON_PCONNECT .

I assume that every couple of minutes you hit a closed (timeout, whatever...) connection in the pool connection. mysqlnd tries to send a COM_CHANGE_USER, fails and bails. ext/mysqli recognizes the failure and continues as it should. Its the same procedure as with ext/mysql and a failing ping - just a bit more verbose...

What MySQL version are you running? Very old and very early 5.1 (<5.1.10 or something like that) servers had issues with COM_CHANGE_USER.

 [2009-10-04 16:25 UTC] oliviapurvis at yahoo dot com
I'm using MySQL 5.1.37.

I have 2 variables set in mysqld that might have affected this:
wait_timeout = 300
interactive_timeout = 300

Are these too low and do they have any connection with the PHP warning?
 [2009-10-04 18:34 UTC] uw@php.net
5.1.37 should be fine to my knowledge.

The timeouts should be described in the MySQL manual. Their values appear "normal" to me. Please ask on one of the discussion lists what value may be best - in the end this is a bug system not a discussion list. 

As said, I believe that you get the warning because you occasionally hit a connection that has timed out or similar - nothing to worry about: PHP simply picks the next connection from the pool or opens a new one. The same can happen with ext/mysql. The only difference is that ext/mysqli @ mysqlnd is a bit more verbose...

The only question here is if a) libmysql also barks and b) if we want that warning or not. Maybe the warning should be suppressed because its handled internally.

Assigning to myself to discuss with Andrey and Johannes.
 [2009-10-15 20:46 UTC] svn@php.net
Automatic comment from SVN on behalf of uw
Revision: http://svn.php.net/viewvc/?view=revision&revision=289684
Log: Making mysqlnd emit no warnings when fetching pooled persistent connections that have timed out or are unusable for any other reason - bug #49761
 [2009-10-15 20:49 UTC] uw@php.net
I have comittet a change to silence CHANGE_USER when reusing pooled persistent connections. The warning should no longer appear. 

The change should either make it into 5.3.1 or 5.3.2 - that is up to the release manager to decide. It is not a critical change. 
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Mar 28 22:01:26 2024 UTC