You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Greetings.
Using psysh v10.8 (great job BTW) to break in a moodle module I am developing. It appears that this causes the mysqli connection to go away in a semi-random fashion (meaning moving breaks around results in different outcomes).
The diagnostic is:
Couldn't fetch mysqli in [...]/lib/dml/mysqli_native_moodle_database.php
This error is always present at exit, but it does also appear during program execution depending on the breakpoint(s) location (and just before errors, $DB->mysqli->ping() returns indeed false).
I use ^D to get out of a breakpoint and continue execution, and I am speculating that the destructor for the global $DB object is called when i do that (the destructor calls mysqli->close()).
Is that what I am seeing, and if so, can it be avoided?
I put together a minimal CLI script illustrating the issue.
This (given correct credentials: replace username and password in the code) runs to the end if invoked as php cli.php while bombing on the second and third ->ping() (and ->close) if invoked as php cli.php -d. This with either mysqli.reconnect=Off or On in php.ini
Yep, confirmed with your repro script. It seems like mysqli doesn't play nice with forking. It's probably that one of the other threads automatically cleaned up the connection while the main thread wasn't looking?
I've also confirmed that disabling pcntl via the psysh config fixes your issue.
That's it. I can make the same happen, with no psysh in the loop, by opening a connection, forking, using it in children processes and exiting. After the first child terminates, the connection becomes useless for evey other process in the group (parent or child). I get "Mysql has gone away", not "couldn't fetch mysqli" but I think the root cause is the same. Mysql documentation mentions terminating connections on client exit, which could be the cause. I searched to see if signals are involved and, if so, ways to trap them before mysql gets wind of them, but no luck.
Updated the Troubleshooting page of the wiki. I'm not sure what else we can do with it from our end, especially since the error happens after the shell exits? ¯_(ツ)_/¯
Activity
MonsieurCellophane commentedon Jul 2, 2021
I put together a minimal CLI script illustrating the issue.
This (given correct credentials: replace username and password in the code) runs to the end if invoked as
php cli.phpwhile bombing on the second and third ->ping() (and ->close) if invoked asphp cli.php -d. This with either mysqli.reconnect=Off or On in php.iniMonsieurCellophane commentedon Jul 2, 2021
Also:
bobthecow commentedon Jul 2, 2021
Try disabling forking (
'usePcntl' => falsein psysh config ).bobthecow commentedon Jul 3, 2021
Yep, confirmed with your repro script. It seems like mysqli doesn't play nice with forking. It's probably that one of the other threads automatically cleaned up the connection while the main thread wasn't looking?
I've also confirmed that disabling pcntl via the psysh config fixes your issue.
MonsieurCellophane commentedon Jul 5, 2021
That's it. I can make the same happen, with no psysh in the loop, by opening a connection, forking, using it in children processes and exiting. After the first child terminates, the connection becomes useless for evey other process in the group (parent or child). I get "Mysql has gone away", not "couldn't fetch mysqli" but I think the root cause is the same. Mysql documentation mentions terminating connections on client exit, which could be the cause. I searched to see if signals are involved and, if so, ways to trap them before mysql gets wind of them, but no luck.
bobthecow commentedon Feb 21, 2022
Updated the Troubleshooting page of the wiki. I'm not sure what else we can do with it from our end, especially since the error happens after the shell exits? ¯_(ツ)_/¯