mysqli_connect(): (HY000/2002): Can't connect to local MySQL server through socket

RixStix:

It only made sense to me that if cPanel restarted the database server, there should be some record of "WHY" that happened. Haven't heard anything yet from that comment to host.

cPanel doesn't restart anything. This is a selection of tools for end users, not so much site admins.

It is the kernel code that handles things like server crashes, killing wayward processes, restarting services, etc.

RixStix:

VPS SSH access is available. I've never needed it (that I knew of), so never asked. So I wouldn't know it if it hit me 'tween the eyes or how to access. :huh:

SSH = 'Secure Shell' - It is just another server process like SQL, HTTP, FTP, TELNET, and so on. You access it with an SSL client (such as 'Putty' http://www.putty.org/)

There may even be an SSH client available to use via your cPanel (although these tend to be horrible to use).

Assuming you are using Putty, you'll open up a connection to your VPS, which will give a DOS like command prompt.

You can then (or should be able to issue a command
cp /var/log/kern.log /var/www/public_html/

This will copy the kernel log file into your public_html folder, where you'll be able to read/view/download it via your cPanel.

If you get a 'file not found' error, you'll need to do a bit of searching to find the file.

"cd" will change your current folder/directory
"ls" will give a list of filenames and folders in whatever folder/directory you are in.

"cd /" will be your 1st command - this will take you to the topmost folder/directory of the server. An 'ls' at this point should reveal folders like 'boot', 'bin', 'sbin', 'home', 'root', 'tmp' 'usr' and 'var'.

The system log files are always found in the '/var' folder/directory.

If you feel this is beyond you, ask your host to provide you with a copy of the file. Or better yet, since they are charging you to manage the server, they should be able to review this log file (and any others) and be able to tell you exactly what is causing the problem. That is why these log files exist. :-)

Cheers
RodG

RodG:

cPanel doesn't restart anything. This is a selection of tools for end users, not so much site admins.

It is the kernel code that handles things like server crashes, killing wayward processes, restarting services, etc.

Maybe the support guys were 'dumbing it down' for me when they said, "The only thing related that I can think of is that it was automatically
restarted due to a system issue. cPanel has many monitoring scripts, and it will restart services automatically when needed."

RodG:

If you feel this is beyond you, ask your host to provide you with a copy of the file. Or better yet, since they are charging you to manage the server, they should be able to review this log file (and any others) and be able to tell you exactly what is causing the problem. That is why these log files exist. :-)

Cheers
RodG

Looking at files is not beyond what I consider my capabilities. I don't start editing stuff without a reasonable expectation of the results and have also learned that "Backup is my Friend" before any edit.

It's past my stopping point today, so I will resume things tomorrow. Thank you for the lesson. I do actually learn quite a bit from your posts. :smile:

RixStix:

Looking at files is not beyond what I consider my capabilities.

I was actually referring to using SSH and the command line. :-)

Many people find anything other than a point n click interface 'too difficult'. It's just the way things are.

Cheers
RodG

We have a "Trophy" for this particular instance. Host had an issue with a "Switch" where the VMhost lost connectivity with the datastore temporarily. They didn't notice any issues but "It" went into read-only mode on the disk.

No trophy for the Aug 1/2 instance. I like trophies. Without a trophy, the same issue is likely to reappear in the future.

RixStix:

We have a "Trophy" for this particular instance. Host had an issue with a "Switch" where the VMhost lost connectivity with the datastore temporarily. They didn't notice any issues but "It" went into read-only mode on the disk.

Although it is good that they (apparently) found something amiss - but it doesn't really explain why the SQL server would have ended up with a corrupted database - Well, it wouldn't explain it if they were physical devices - Things can be a little different when virtualized though, so I'll put this down as being a feasible cause/explanation. :-)

Cheers
RodG

I've been seeing more and more of these type logs on installations using Zen Cart versions 1.5.2+ (i.e. using mysqli instead of mysql). It's not host-specific or, that I've seen, PHP/MySQL version-specific. The latest bunch are a mixture of:

[14-Apr-2016 18:01:32 America/New_York] Request URI: /mystore/index.php?main_page=product_info&cPath=311_79&products_id=2956, IP address: xx.yy.zz.ww
#1  mysqli_connect() called at [/home/mystore/public_html/store/includes/classes/db/mysql/query_factory.php:62]
#2  queryFactory->connect() called at [/home/mystore/public_html/store/includes/init_includes/init_database.php:23]
#3  require(/home/mystore/public_html/store/includes/init_includes/init_database.php) called at [/home/mystore/public_html/store/includes/autoload_func.php:48]
#4  require(/home/mystore/public_html/store/includes/autoload_func.php) called at [/home/mystore/public_html/store/includes/application_top.php:158]
#5  require(/home/mystore/public_html/store/includes/application_top.php) called at [/home/mystore/public_html/store/index.php:26]

[14-Apr-2016 18:01:32 America/New_York] PHP Warning:  mysqli_connect(): (HY000/2002): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2) in /home/mystore/public_html/mystore/includes/classes/db/mysql/query_factory.php on line 62

and

[06-Apr-2016 13:49:45 America/New_York] Request URI: /store/the_admin/orders.php?oID=6475&action=edit, IP address: xx.yy.zz.ww
#1  mysqli_connect() called at [/home/mystore/public_html/store/includes/classes/db/mysql/query_factory.php:62]
#2  queryFactory->connect() called at [/home/mystore/public_html/store/the_admin/includes/init_includes/init_database.php:19]
#3  require(/home/mystore/public_html/store/the_admin/includes/init_includes/init_database.php) called at [/home/mystore/public_html/store/includes/autoload_func.php:48]
#4  require(/home/mystore/public_html/store/includes/autoload_func.php) called at [/home/mystore/public_html/store/the_admin/includes/application_top.php:156]
#5  require(/home/mystore/public_html/store/the_admin/includes/application_top.php) called at [/home/mystore/public_html/store/the_admin/orders.php:10]

[06-Apr-2016 13:49:45 America/New_York] PHP Warning:  mysqli_connect(): (08004/1040): Too many connections in /home/mystore/public_html/store/includes/classes/db/mysql/query_factory.php on line 62

Anybody got any ideas?

lat9:

I've been seeing more and more of these type logs on installations using Zen Cart versions 1.5.2+ (i.e. using mysqli instead of mysql). It's not host-specific or, that I've seen, PHP/MySQL version-specific. The latest bunch are a mixture of:

PHP Warning: mysqli_connect(): (HY000/2002): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2)

> ```
PHP Warning:  mysqli_connect(): (08004/1040): Too many connections

Anybody got any ideas?
I think it's that most hosts haven't updated their internal processes to optimize the mysqli client. Perhaps their old procedures were only for configuring the mysql client.

PHP Warning:  mysqli_connect(): (HY000/2002): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2)

The socket error is typically a result of either:
a) The MysQL engine is overloaded and not responding, or is down. This is a host issue.
b) The configuration in php.ini for the mysqli client isn't pointing to a valid mysql.sock file (in the case of using sockets instead of IP addresses). This would cause ALL connections to mysqli from PHP to fail. So if what you're seeing is intermittent, then the above "a)" point is the more likely issue.

PHP Warning:  mysqli_connect(): (08004/1040): Too many connections
```Perhaps the my.cnf master configuration for MySQL on this server has not been configured large enough for the kind of traffic this server is getting. That's the usual cause of this message.
Sometimes it's the same cause but also exaggerated by apps opening connections but not closing them properly. 
It could also be further aggravated by the max connect time being set to too long in the my.cnf so that connections don't automatically close quickly enough after queries are done.
Typically a host issue, where the server is not tuned to match the load/demand that the application is putting on it.

My 2 cents anyway.

I've once caused the too many connections issue by causing a cyclic loop (while loop without proper incrementation to cause the while to go false), it was dependent on other factors to get there and therefore intermittent.

There you go, lat9! Just blame mc12345678! Quick solution :D

/me ducks and hides ...

DrByte:

There you go, lat9! Just blame mc12345678! Quick solution :D

/me ducks and hides ...

:smartalec: would deserve that if it wasn't on my development server and where I had forgotten to use a $query->MoveNext() operation in the loop to iterate through the "mess" of the old style query results. :P go back to your idgits. :P Ya kuke.

For anyone else reading this, there are no shots being taken at DrByte, I'm aware of the kind of day he's had and somewhat surprisingly (or not) seems to be something contagious as have had similar.

mc12345678:

:smartalec: would deserve that if it wasn't on my development server and where I had forgotten to use a $query->MoveNext() operation in the loop to iterate through the "mess" of the old style query results. :P go back to your idgits. :P Ya kuke.

For anyone else reading this, there are no shots being taken at DrByte, I'm aware of the kind of day he's had and somewhat surprisingly (or not) seems to be something contagious as have had similar.
Hahaha!