Unable to connect to mysql database

Are you sure MySQL itself is not down? Try "telnet localhost 3306" if you are unsure. If that is responding then exit the telnet and continue troubleshooting.

At the top of /etc/cron.hourly/modsecparse.pl you should see something like this:

my $dbhost = 'localhost';
my $dbuser = 'modsec';
my $dbpassword = '20h0j24hg039u4g';
my $dbname = 'modsec';
my $tblname = 'modsec';

At root SSH prompt try this:

# mysql -u modsec -p

You should get a prompt "Enter password;", enter the my $dbpassword password like 20h0j24hg039u4g

This should connect to MySQL,

The MySQL prompt should let you do this:

Code:

mysql> show databases ; 
+--------------------+
| Database           |
+--------------------+
| information_schema | 
| modsec             | 
+--------------------+
2 rows in set (0.00 sec)

If you get an error from mysql -u modsec -p when trying to connect then likely the username/password is wrong, and you need to manually re-set the password for 'modsec' to match the password in modsecparse.pl

if you can connect to MySQL but the database 'modsec' does not show from "show databases ; " then the database is missing or the modsec user is not granted permissions.

 

Same problem here.

Notice that it started when Mysql updated to V5.1.73 according to the timestamp on /var/lib/mysql/mysql_upgrade_info (and assuming it was updated at that time as the contents of the file are simply 5.1.73 )

I have verified that I can connect to the database as the user.

The error message states that the modsecparse.pl script is trying to connect to the socket at /tmp/mysql.sock, but the location of the socket is /var/lib/mysql/mysql.sock

Personally, I hate changing any cpanel script to get around this (or any other cpanel issues) as the next cpanel update might simply over-write it and I would be back to fixing it again.

For those that don't want to wait the hack is actually trivial - on line 13 - comment it out and force it to use the socket at the correct location.

Code:

# my $dbhost     = 'localhost';
my $dbhost     = 'mysql_socket=/var/lib/mysql/mysql.sock';

Ideally, the script SHOULD, rather than use a localhost connection, is to determine the actual location of the socket file, then set the value.

But at least for now, until this script is updated, I will stop getting these annoying cron job messages.

Output before modification

Code:

root@host [/]# /etc/cron.hourly/modsecparse.pl
DBI connect('modsec:localhost','modsec',...) failed: Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2) at /etc/cron.hourly/modsecparse.pl line 19
Unable to connect to mysql database at /etc/cron.hourly/modsecparse.pl line 19.
root@host [/]# 

Output AFTER modification

Code:

root@host [/]# /etc/cron.hourly/modsecparse.pl
root@host [/]#

 

On my system, /tmp/mysql.sock is just a symlink to /var/lib/mysql/mysql.sock, and I did not create this symlink. Perhaps your symlink was missing for some reason.

lrwxrwxrwx 1 root root 30 Mar 14 16:50 mysql.sock -> ../../var/lib/mysql/mysql.sock=

Most likely you could just:

Code:

cd /tmp
ln -s ../../var/lib/mysql/mysql.sock mysql.sock

If I remove the symlink I get the connection error, when I recreate it everything is fine. No editing of the /etc/cron.hourly/modsecparse.pl was required.

 

Well, that in itself is a bug as far as I am concerned.

Nothing within /tmp should be critical to the operation and is a Temporary File - so yes, if there has been a sym-link to the socket file in the past, then this has been a problem for a lot longer than the last several days.

All in all, this is a bug within the script that does not properly identify the location of the socket (and no, a sym-link is not the location of the socket) or correctly use a network connection (loopback) to the db.

- - - Updated - - -

Bug Report submitted that references this thread. Ticket 4673889

 

I've just run into this after a reboot for a kernel upgrade. Restarting mysql via the script for doing so put the symlink into tmp, As normal (by the looks from boot.log) the secure tmp was set up before mysql started. Having issued another reboot can't reproduce the problem, subscribing in case anyone finds the root cause.

 

Same issue here after rebooting from a kernel update and fixed by adding the symlink back.

 

Unfortunately, not fixed.

CP just updated to 11.44.x a re-build of Apache and yep, had to re-apply the fix.

How hard is it to actually parse the my.cnf file to find the configured location of a socket file rather than wrongly relying on something in /tmp

Have you not heard of tmpwatch people? Heck, even if there was a sym-link from /tmp to the correct location of the socket chances are it would not survive more than a day!

 

I am having the same issue, and I don't seem to have any /tmp/mysql.sock file.
Manually changing my $dbhost to point to 'mysql_socket=/var/lib/mysql/mysql.sock'; like rrwh mentioned above seems to work for now, but is there an official fix coming for this?
Thanks!

 

I fixed this issue on my server by enable mysql monitoring in WHM >> service manager