We have been working with LiteSpeed technical support to identify the reason for it shutting down the MySQL service and we now have a working theory and possible fix.
It would appear that under some circumstances when a MySQL thread uses a recycled lsphp process id it can get shut down by LiteSpeed. LiteSpeed is issuing a kill -9 to the thread process id but this actually gets logged in the Audit trail as a kill -9 to the main MySQL process id so it shuts down.
This explains why we have only ever seen this problem on our busier servers. All of our servers pid_max are set to the default of 4194304 (cat /proc/sys/kernel/pid_max) and that range is easily being hit so pid recycling starts to happen.
LiteSpeed support have provided a test fix for this in their debug builds but as of yet we have been unable to get the debug build to work properly under enhance so we can't comment on if this has fixed it yet.
If you want to test this yourself then feel free to install the latest debug build:
Please be aware that this is a DEBUG build you are installing so I accept no responsibility for what it does
/usr/local/lsws/admin/misc/lsup.sh -d -f -v 6.3.2
That being said, if you have any problems you can easily revert back to the latest STABLE build with:
/usr/local/lsws/admin/misc/lsup.sh -f -v 6.3.2
As I find out more I will let you know.
