error: 'Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2 "No such file or directory") [GELÖST]

[Jolinar]

Hallo,

wie der Topic schon sagt, habe ich Probleme mit dem DB-Server.

Ausgangssituation:
- KVM-Server mit vom Hoster bereitgestelltem Image (Debian Jessie) neu aufgesetzt
- Pakete aktualisiert (apt-get update && apt-get upgrade)
- Reboot
- keyhelp installiert

Installation lief fehlerfrei durch und keyhelp ließ sich auch ohne erkennbare Probleme nutzen.
Da ich die bin-Logs deaktivieren wollte, habe ich den DB-Server gestoppt (systemctl stop mysql.service), die my.cnf entsprechend bearbeitet und gespeichert und wollte den DB-Server neu starten (systemctl start mysql.service), was aber mit einer Fehlermeldung quittiert wurde:

Code: Select all

Job for mysql.service failed. See 'systemctl status mysql.service' and 'journalctl -xn' for details.

Ein systemctl status mysql.service bringt folgende Ausgabe:

Code: Select all

/etc/init.d/mysql[5551]: 0 processes alive and '/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf ping' resulted in
/etc/init.d/mysql[5551]: [61B blob data]
/etc/init.d/mysql[5551]: error: 'Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2 "No such file or directory")'
/etc/init.d/mysql[5551]: Check that mysqld is running and that the socket: '/var/run/mysqld/mysqld.sock' exists!
/etc/init.d/mysql[5551]:
mysql[4973]: Starting MariaDB database server: mysqld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . failed!
systemd[1]: mysql.service: control process exited, code=exited status=1
systemd[1]: Failed to start LSB: Start and stop the mysql database server daemon.
systemd[1]: Unit mysql.service entered failed state.

Interessanterweise wird der DB-Server bei einem Reboot ordnungsgemäß gestartet, was für mich allerdings ein nur sehr unbefriedigender Workaround wäre.

Um auszuschließen, daß das Problem in dem vom Hoster bereitgestellten OS-Image begründet sein könnte, habe ich die Situation in einer lokalen virtualbox-VM reproduziert, wobei ich hier ein wirklich minimales System aufgesetzt habe, wo lediglich der SSH-Server bei der Systeminstallation dabei ist.
Das Fehlerbild ist identisch, es liegt auch nicht an meinem Eingriff in die my.cnf, da bereits ein systemctl restart mysql.service zum Ausfall des DB-Servers führt. Auch in der lokalen VM bewirkt ein Reboot einen normalen Start des DB-Servers.
Eigentümer und Verzeichnisrechte der Verzeichnisse /var/lib/mysql, /var/run/mysqld und /var/log/mysql sind korrekt gesetzt.

Hat jemand eine Idee, wo das Problem liegen könnte?

[Martin]

Hallo,

welche Version von mySQL ist installiert und war diese bereits vor der KeyHelp Installation auf dem System eingerichtet?

[Jolinar]

welche Version von mySQL ist installiert und war diese bereits vor der KeyHelp Installation auf dem System eingerichtet?

Der installierte DB-Server ist ein 10.0.23-MariaDB-1~jessie

Beide Testumgebungen, sowohl beim Hoster als auch die lokale VM wurden minimal, also Grundsystem + SSH-Server, aufgesetzt. Sämtliche Installationen (Mail-, Web-, DB-Server, etc.) wurden vom keyhelp-Installer durchgeführt.

Nachtrag:
Im Startpost hatte ich vergessen zu erwähnen, daß ein Restart des DB-Servers über die keyhelp Web-GUI ebenfalls fehlschlägt.

[Martin]

Hallo,

dies ist in der Tat ein ungewöhnliches Verhalten, was wir so bisher nicht beobachten konnten, auch nicht bei Debian 8 Systemen.

Gibt es im Syslog oder mySQL Log ggf. einen Anhaltspunkt warum der Start des DB Servers fehl schlägt? (ggf. InnoDB beschädigt?)
Der bisherige Logauszug ist hier leider wenig aussagekräftig.

Mir ist es bisher auch nicht gelungen das Verhalten nachzustellen (Debian 8 netinstall + minimale Paketauswahl)

[Jolinar]

Okay, nach ein wenig intensiverer Fehlersuche bin ich auf das Problem gestoßen.
Ich habe bei meinem System 1GB RAM und die in der /etc/mysql/conf.d/tuning.cnf festgelegten Werte waren für mein System viel zu hoch.
Nach dem Herabsetzen des Wertes für innodb_buffer_pool_size läßt sich der DB-Server auch restarten.
Das zugrundeliegende Problem erklärt auch, warum der DB-Server bei einem Reboot startet, da zum Zeitpunkt des DB-Server Starts andere Speicherfresser (AV- und Spam-Tools) noch nicht geladen sind und demzufolge noch wesentlich mehr RAM zur Verfügung steht als bei einem Restart des DB-Servers.

Dazu noch eine grundsätzliche Anmerkung:
Das Problem wird (vermutlich) bei allen Maschinen auftauchen, deren Hauptspeicher nicht allzu üppig ausgestattet ist. Aktuell wird vom Installer eine tuning.cnf mit fixen Werten ins System eingepflegt.
Hier müßte vom Installer ein Check über die Größe des verfügbaren RAM erfolgen und in Abhängigkeit des Ergebnisses müßten die Werte in der DB-Config entsprechend angepaßt werden, damit keyhelp wirklich DAU-tauglich wird.

Wenn ich auf diesen Ansatz im Forenbereich "Funktionswünsche" nochmal näher eingehen soll, bitte kurze Rückinfo. Ansonsten bitte auf die ToDo-Liste setzen

[Martin]

Hallo,

vielen Dank für den Hinweis. Ich habe den Vorschlag an unseren Entwickler weitergeleitet.

[Jolinar]

Da ich selber den Topic im Startpost nicht editieren kann, die Frage an die Moderation, ob der Topic als [gelöst] gekennzeichnet werden könnte.
Das dürfte die Übersichtlichkeit hier im Board erhöhen und auch zukünftige Suchergebnisse bei Google & Co. verbessern.

[Martin]

Hallo,

ich habe das Thema entsprechend markiert und Benutzer haben künftig die Möglichkeit die Themen selbst entsprechend zu markieren.