That’s a bit of an onerous fix to apply yourself though, even if true. All of my research reveals that Darwin’s poll() handles all of the events necessary to use it instead of select(). I suspect but have not tested that switching back to poll() and recompiling MySQL would be fine for modern versions of OS X. File Descriptor 1043 exceedeed FD_SETSIZE=1024 A potential workaround? And if you check your MySQL error log, you’ll see the more detailed message like: 1 The result is the “MySQL server has gone away” error above. Oracle fixed this recently by rejecting the connection request outright.
This switch to using select() resulted in a new bug that caused stack corruption on OS X when the file descriptors exceeded 1024. So as with many other Unix systems, select() is stuck with the limitation of 1024 file descriptors. Darwin-OS X’s Unix core-is one of the Unix versions where recompiling is not an option, as you can’t compile your own version of OS X. Most Unix versions have a default max of 1024 for FD_SETSIZE, and you cannot configure it at runtime. MySQL can potentially spin up hundreds for the files it uses for your databases, pushing over that limit. Select() has a default limitation of handling 1024 file descriptors. Oracle noticed this bug with kill on OS X using poll() and switched to select().
On MySQL 5.6.8 and lower, you would have had some kill issues, but probably never noticed as PHP would make a new connection and be on its way. So PHP’s connection would close, but MySQL server would think it was still open, and wait out the default 28800 second timeout before closing it. In the case of OS X-and it’s unclear if this is true on OS X > 10.4.4- poll() didn’t handle the POLLHUP event to “hang up” the connection. In fact, its behavior is not even consistent within a single implementation. But not all flavors of Unix implement poll() identically. Poll() is typically preferred due to some limitations of select(), which will become clear in a moment. The two most common on Unix-based systems are poll() and select(). MySQL uses your OS’s system-level functions to track the availability of input/output channels. You might be able to prevent this by dramatically reducing MySQL’s interactive_timeout and wait_timeout. Restarting the server will fix it until the next time this occurs.
Tl dr: MySQL 5.7 will break on OS X after too many connections are left open within eight hours. MySQL and Unix internals are not my wheelhouse, so if I get some details wrong, please let me know so I can correct them. I finally tracked it down so I thought I’d share my frustration and make this issue a bit more discoverable. Have you seen this error show up randomly while working in your local environment? I started getting this error randomly after updating to MySQL 5.7, and it’s really bugged me. system/ee/legacy/database/drivers/mysqli/mysqli_connection.php:82