MySQL error 2006: MySQL server has gone away

Hello Community,

I’m currently evaluating SuiteCRM, having used vTiger and Sugar in the past and looking to potentially implement a paid CRM like Capsule.

My concern (based on experience) with many of the opensource CRM offerings is that they are very temperamental.

After installation of SuiteCRM, I seem to be seeing a lot of MySQL connection problems as follows;

[9157][-none-][FATAL] Retrieving record by id users:1 found Query Failed: SELECT users.* FROM users WHERE = ‘1’ AND users.deleted=0 LIMIT 0,1: MySQL error 2006: MySQL server has gone away

On checking the server max_allowed_packet it is already set to around 500M so it is unlikely to be that.

There is a wait_timeout set to around 60 seconds and ideally, any PHP script should react to this error by attempting to reconnect at least once, rather than just erroring out.

I’m at a loss as to the cause and how to resolve this. Could anybody offer any advice?

Many thanks

Hi, welcome to the Community! :tada:

I’ve seen this error before, and it was always some infrastructure problem in the stack, not a SuiteCRM problem.

It’s a MYSQL crash, essentially, There are many possible causes, I am afraid:

I don’t think it’s just a timeout, it’s something deeper that is usually solved either with new hardware (in the rare case of intermittent failure of RAM or network card), or a new installation of MySQL, or some other component in the underlying OS.

BTW if you provide more details about your versions (OS, MySQL, PHP, SuiteCRM) that usually helps narrow things down.

Thanks or responding pgr.
I’m not convinced that it’s a stack problem. I’m running other apps without a problem.

PHP Version 7.3.15

System Linux 3.10.0-962.3.2.lve1.5.26.7.el7.x86_64 #1 SMP Wed Oct 2 07:53:12 EDT 2019 x86_64
Build Date Feb 20 2020 13:18:18
Configure Command ‘./configure’ ‘–disable-dependency-tracking’ ‘–prefix=/usr’ ‘–exec-prefix=/usr’ ‘–bindir=/usr/bin’ ‘–sbindir=/usr/sbin’ ‘–sysconfdir=/etc’ ‘–datadir=/usr/share’ ‘–includedir=/usr/include’ ‘–libdir=/usr/lib64’ ‘–libexecdir=/usr/libexec’ ‘–sharedstatedir=/var/lib’ ‘–mandir=/usr/share/man’ ‘–infodir=/usr/share/info’ ‘–build=x86_64-redhat-linux-gnu’ ‘–host=x86_64-redhat-linux-gnu’ ‘–target=x86_64-redhat-linux-gnu’ ‘–program-prefix=’ ‘–prefix=/opt/alt/php73’ ‘–exec-prefix=/opt/alt/php73’ ‘–bindir=/opt/alt/php73/usr/bin’ ‘–sbindir=/opt/alt/php73/usr/sbin’ ‘–sysconfdir=/opt/alt/php73/etc’ ‘–datadir=/opt/alt/php73/usr/share’ ‘–includedir=/opt/alt/php73/usr/include’ ‘–libdir=/opt/alt/php73/usr/lib64’ ‘–libexecdir=/opt/alt/php73/usr/libexec’ ‘–localstatedir=/var’ ‘–with-curl=/opt/alt/curlssl/usr’ ‘–sharedstatedir=/usr/com’ ‘–mandir=/opt/alt/php73/usr/share/man’ ‘–infodir=/opt/alt/php73/usr/share/info’ ‘–cache-file=…/config.cache’ ‘–with-libdir=lib64’ ‘–with-config-file-path=/opt/alt/php73/etc’ ‘–with-config-file-scan-dir=/opt/alt/php73/link/conf’ ‘–disable-debug’ ‘–enable-calendar’ ‘–enable-exif’ ‘–enable-ftp’ ‘–enable-huge-code-pages’ ‘–enable-opcache’ ‘–enable-opcache-file’ ‘–enable-shmop’ ‘–enable-unicode’ ‘–enable-xml’ ‘–with-bz2’ ‘–with-freetype-dir=/usr’ ‘–with-gettext’ ‘–with-gmp’ ‘–with-iconv’ ‘–with-jpeg-dir=/usr’ ‘–with-kerberos’ ‘–with-layout=GNU’ ‘–with-libxml-dir=/opt/alt/libxml2/usr’ ‘–with-mhash’ ‘–with-openssl-dir=/opt/alt/openssl’ ‘–with-openssl=/opt/alt/openssl’ ‘–with-password-argon2=/usr’ ‘–with-pcre-jit’ ‘–with-pcre-regex’ ‘–with-pic’ ‘–with-png-dir=/usr’ ‘–with-readline’ ‘–with-t1lib=/opt/alt/t1lib/usr’ ‘–with-webp-dir=/usr’ ‘–with-xpm-dir=/usr’ ‘–with-zlib’ ‘–with-zlib-dir=/usr’ ‘–without-gdbm’ ‘–without-pear’ ‘–with-litespeed’ ‘–enable-pcntl’ ‘–without-mysqli’ ‘–disable-mbstring’ ‘–disable-bcmath’ ‘–disable-dba’ ‘–disable-dom’ ‘–disable-fileinfo’ ‘–disable-json’ ‘–disable-intl’ ‘–disable-pdo’ ‘–disable-phar’ ‘–disable-posix’ ‘–disable-soap’ ‘–disable-sockets’ ‘–disable-sysvsem’ ‘–disable-sysvshm’ ‘–disable-sysvmsg’ ‘–disable-wddx’ ‘–disable-xmlreader’ ‘–disable-xmlwriter’ ‘–disable-zip’ ‘–without-gd’ ‘–without-imap’ ‘–without-xmlrpc’ ‘–without-xsl’ ‘–without-ldap’ ‘–without-pgsql’ ‘–without-snmp’ ‘–without-sodium’ ‘–without-tidy’ ‘–without-enchant’ ‘–without-recode’ ‘–without-mssql’ ‘–without-pspell’ ‘–without-unixODBC’ ‘build_alias=x86_64-redhat-linux-gnu’ ‘host_alias=x86_64-redhat-linux-gnu’ ‘target_alias=x86_64-redhat-linux-gnu’ ‘CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -fno-strict-aliasing -Wno-pointer-sign’ ‘CXXFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic’
Server API LiteSpeed V7.6
Virtual Directory Support disabled
Configuration File (php.ini) Path /opt/alt/php73/etc
Loaded Configuration File /opt/alt/php73/etc/php.ini
Scan this dir for additional .ini files /opt/alt/php73/link/conf
Additional .ini files parsed /opt/alt/php73/link/conf/alt_php.ini
PHP API 20180731
PHP Extension 20180731
Zend Extension 320180731
Zend Extension Build API320180731,NTS
PHP Extension Build API20180731,NTS
Debug Build no
Thread Safety disabled
Zend Signal Handling enabled
Zend Memory Manager enabled
Zend Multibyte Support provided by mbstring
IPv6 Support enabled
DTrace Support disabled
Registered PHP Streams https, ftps, compress.zlib, compress.bzip2, php, file, glob, data, http, ftp, zip, phar
Registered Stream Socket Transports tcp, udp, unix, udg, ssl, sslv3, tls, tlsv1.0, tlsv1.1, tlsv1.2
Registered Stream Filters zlib., bzip2., convert.iconv., string.rot13, string.toupper, string.tolower, string.strip_tags, convert., consumed, dechunk, mcrypt., mdecrypt.


MysqlI Support enabled
Client API library version 5.7.29
Active Persistent Links 0
Inactive Persistent Links 0
Active Links 0
Client API header version 5.7.29
MYSQLI_SOCKET /var/lib/mysql/mysql.sock

Version 7.11.12

Sugar Version 6.5.25 (Build 344)

1 Like

I’ve seen basically every thread on these forums for the past 3 years or so, and everything on our GitHub also. I’ve come across this error some 10 or 15 times, and it was never solved by anything we did on SuiteCRM’s side. People just tweak their systems and their settings until the problem suddenly evaporates.

Note what this is: SuiteCRM asks your DB for a query result; your DB process crashes with its ugliest error. It’s not complaining about a malformed query or something, it is crashing.

That said, we should try and find out ways to take your system to a point where this isn’t happening.

A few things that come to mind for you to check…

These settings in your php.ini:

  • memory_limit
  • max_execution_time

See if those are generous enough and restart web server if you change anything.

My host tried all that and it made no difference.
Simply switching from port 465 to 25 with TLS solved the problem.

Hhm I wonder what is the actual explanation behind that weird behaviour… :thinking:

Anyway, I am glad you got it working now :+1:

yes indeed … I will plough on for now though

1 Like