Issue MYSQL is down and does not start anymore / SQLSTATE[HY000] [2002] No such file or directory

[mariodieck]

Hi everybody, I noticed that my website and Plesk are not working anymore.

PLSEK reports

Server error
500
Zend_Db_Adapter_Exception
SQLSTATE [HY000] [2002] No such file or directory

I had then joined me and restarted MYSQL and I got the following

puck435: ~ # /etc/init.d/mysql start

[....] Starting mysql (via systemctl): mysql.serviceJob for mysql.service failed. See 'systemctl status mysql.service' and 'journalctl -xn' for details.
failed!

systemctl status mysql.service outputs the following

● mysql.service - LSB: Start and stop the mysql database server daemon
   Loaded: loaded (/etc/init.d/mysql)
   Active: failed (Result: exit-code) since Thu 2019-03-28 10:02:49 CET; 45s ago
  Process: 11219 ExecStart = /etc/init.d/mysqlstart (code = exited, status = 1 / FAILURE)

Mar 28 10:02:19 puck435 mysqld [11402]: / usr / sbin / mysqld [0x52ac45]
Mar 28 10:02:19 puck435 mysqld [11402]: / usr / sbin / mysqld (_Z11mysqld_mainiPPc + 0x57b) [0x5307db]
Mar 28 10:02:19 puck435 mysqld [11402]: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7fc99acc1b45]
Mar 28 10:02:20 puck435 mysqld [11402]: / usr / sbin / mysqld [0x526221]
Mar 28 10:02:20 puck435 mysqld [11402]: The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
Mar 28 10:02:20 puck435 mysqld [11402]: information that should help you find out what is causing the crash.
Mar 28 10:02:49 puck435 mysql [11219]: Starting MariaDB database server: mysqld. , , , , , , , , , , , , , , ... iled!
Mar 28 10:02:49 puck435 systemd [1]: mysql.service: control process exited, code = exited status = 1
Mar 28 10:02:49 puck435 systemd [1]: Failed to start LSB: Start and stop the mysql database server daemon.
Mar 28 10:02:49 puck435 systemd [1]: Unit mysql.service entered failed state.
Hint: Some lines were ellipsized, use -l to show in full.

and journalctl -xn gives me the following

- Logs begin at Wed 2019-03-27 20:27:50 CET, end at Thu 2019-03-28 10:04:03 CET. -
Mar 28 10:03:46 puck435 smbd [11869]: pam_unix (samba: session): session closed for user nobody
Mar 28 10:03:47 puck435 smbd [11870]: pam_unix (samba: session): session closed for user nobody
Mar 28 10:03:55 puck435 smbd [11871]: pam_unix (samba: session): session closed for user nobody
Mar 28 10:04:01 puck435 CRON [11874]: pam_unix (cron: session): session opened for user root by (uid = 0)
Mar 28 10:04:01 puck435 CRON [11875]: (root) CMD ([-x / opt / psa / admin / sbin / backupmng] && / opt / psa / admin / sbin / backupmn
Mar 28 10:04:01 puck435 CRON [11874]: pam_unix (cron: session): session closed for user root
Mar 28 10:04:01 puck435 postfix / smtpd [10590]: warning: hostname myort.net does not resolve to address 93.157.63.6
Mar 28 10:04:01 puck435 postfix / smtpd [10590]: connect from unknown [93.157.63.6]
Mar 28 10:04:02 puck435 smbd [11878]: pam_unix (samba: session): session closed for user nobody
Mar 28 10:04:03 puck435 smbd [11880]: pam_unix (samba: session): session closed for user nobody
lines 1-11 / 11 (END) ... skipping ...
- Logs begin at Wed 2019-03-27 20:27:50 CET, end at Thu 2019-03-28 10:04:03 CET. -
Mar 28 10:03:46 puck435 smbd [11869]: pam_unix (samba: session): session closed for user nobody
Mar 28 10:03:47 puck435 smbd [11870]: pam_unix (samba: session): session closed for user nobody
Mar 28 10:03:55 puck435 smbd [11871]: pam_unix (samba: session): session closed for user nobody
Mar 28 10:04:01 puck435 CRON [11874]: pam_unix (cron: session): session opened for user root by (uid = 0)
Mar 28 10:04:01 puck435 CRON [11875]: (root) CMD ([-x / opt / psa / admin / sbin / backupmng] && / opt / psa / admin / sbin / backupmng> / dev / null 2> &1)
Mar 28 10:04:01 puck435 CRON [11874]: pam_unix (cron: session): session closed for user root
Mar 28 10:04:01 puck435 postfix / smtpd [10590]: warning: hostname myort.net does not resolve to address 93.157.63.6
Mar 28 10:04:01 puck435 postfix / smtpd [10590]: connect from unknown [93.157.63.6]
Mar 28 10:04:02 puck435 smbd [11878]: pam_unix (samba: session): session closed for user nobody
Mar 28 10:04:03 puck435 smbd [11880]: pam_unix (samba: session): session closed for user nobody

ls / var / run / mysqld -l gives the following

totally 0

I did not change anything in my.cnf or anywhere else. Then I wanted to read the error.log in var / log / mysql, only this is empty.

Google, I find the one or the other approach, but if that is what I need, I unfortunately do not know because I have not had to deal with MYSQL so far:?

mysql Ver 15.1 Distrib 10.0.38-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2
It is a Linux server with Debian 8. Hope you can help me a little further ...

 

[IgorG]

Check location of error log with something like

# cat /etc/mysql/my.cnf | grep log_error

and сру messages in this log.
Check that you have enough free disk space and inodes.

 

[mariodieck]

Thank you for the fast answer

The log is located in /var/log/mysql/error.log

This log is empty

puck435:~# cat /etc/mysql/my.cnf | grep log_error
log_error = /var/log/mysql/error.log

Space is still available enough

 

[IgorG]

Output of

# df
# df -i

?

 

[mariodieck]

Sorry

df

Filesystem      1K-blocks      Used  Available Use% Mounted on
/dev/md2       1914232204 311824136 1505147628  18% /
udev                10240         0      10240   0% /dev
tmpfs             3280872    148300    3132572   5% /run
tmpfs             8202176         8    8202168   1% /dev/shm
tmpfs                5120         0       5120   0% /run/lock
tmpfs             8202176         0    8202176   0% /sys/fs/cgroup
/dev/md0           483626     56493     402164  13% /boot

df -i

Filesystem        Inodes   IUsed     IFree IUse% Mounted on
/dev/md2       121561088 2070252 119490836    2% /
udev             2040000     394   2039606    1% /dev
tmpfs            2050544     659   2049885    1% /run
tmpfs            2050544       3   2050541    1% /dev/shm
tmpfs            2050544      16   2050528    1% /run/lock
tmpfs            2050544      13   2050531    1% /sys/fs/cgroup
/dev/md0          124928     333    124595    1% /boot

 

[IgorG]

As you can see Plesk Help Center a lot of different reasons for this issue сan be.
Try to apply solutions and contact Plesk Support Team if not help.

 

[mariodieck]

OK, I have once turned to the support

 

[mariodieck]

Hello, would it also work if I try to start the database with the parameter innodb_force_recovery? I know that data can be lost as well. But a try is worth it?

 

[HammyHavoc]

Hello, would it also work if I try to start the database with the parameter innodb_force_recovery? I know that data can be lost as well. But a try is worth it?

Did you ever figure this out?