Mysql neustart nach einem Update

Nein LC sollte m.M.n. auf gar keinen Fall versuchen an diesem Zeitpunkt den MySQL-Server neuzustarten. Es gibt viele Applikationen und selbst ernannte Monitoring-Lösungen die durch so etwas Unheil anrichten.

Zitat von Mogwais

Nach einem apt-get upgrade auf debian wurde der Mysql server gestoppt, aber leider bis liveconfig dran war nicht wieder gestart.

Daraufhin schlug die Verbindungsaufnahme natürlich fehl.

Ich habe ein sehr ähnliches Problem nach einem Server-Reboot:

LC sucht den Socket an der falschen Stelle:

[2015/06/06 23:25:03.345053] [4826|4826] LiveConfig 1.8.3-3577 starting...
[2015/06/06 23:25:03.818567] [4826|4826] Database driver loaded: MySQL (5.5.41)
[2015/06/06 23:25:03.818670] [4826|4826] Connection to MySQL server failed, trying again in 1 second(s). Error 2002: Can't connect to local MySQL server through socket '[COLOR='#008000'][B]/var/run/mysqld/mysqld.sock[/B][/COLOR]' (2)
[2015/06/06 23:25:04.818815] [4826|4826] Connection to MySQL server failed, trying again in 2 second(s). Error 2002: Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)
....
[2015/06/06 23:26:07.142499] [4826|4826] Database connection failed: Can't connect to local MySQL server through socket '[B][COLOR='#FF0000']/tmp/mysql.sock[/COLOR][/B]' (2)

LC muss nach jedem Reboot (Sicherheitsupdates am Kernel) neu gestartet werden.

Per "find -type f | xargs grep sock | grep tmp" in /etc/liveconfig und /usr/lib/liveconfig fand ich keinen Hinweis auf eine passende Konfigurationsmöglichkeit.

Weiß jemand, wie man LC von diesem Verhalten, den Socket an der falschen Stelle in /tmp statt an der passenden Stelle unter /var/run/mysqld/ zu suchen, abbringt?

Debian 7, LC 1.8.3-r3577

Zitat von aho546745

Per "find -type f | xargs grep sock | grep tmp"

Besser:

> grep -HR sock /etc/liveconfig /usr/lib/liveconfig

Zitat

Weiß jemand, wie man LC von diesem Verhalten, den Socket an der falschen Stelle in /tmp statt an der passenden Stelle unter /var/run/mysqld/ zu suchen, abbringt?

Umstellen auf "db_host=127.0.0.1", dann verwendet LiveConfig nicht den Unix-Socket, sondern die TCP-Verbindung.

Zitat von antondollmaier

Besser:

Umstellen auf "db_host=127.0.0.1", dann verwendet LiveConfig nicht den Unix-Socket, sondern die TCP-Verbindung.

passt, danke

Zitat von aho546745

Weiß jemand, wie man LC von diesem Verhalten, den Socket an der falschen Stelle in /tmp statt an der passenden Stelle unter /var/run/mysqld/ zu suchen, abbringt?

LiveConfig ruft zur Verbindung zu MySQL die Funktion "mysql_real_connect()" in einer Schleife auf. Der MySQL-Client wiederum liest seine Einstellungen (u.a. socket) aus /etc/mysql/my.cnf, Abschnitt [client].

Wenn bei einem Reconnect der falsche Socket-Pfad verwendet wird, dann handelt es sich um einen Fehler im MySQL-Client, und nicht in LiveConfig.
[offtopic]Höchste Zeit also, Oracle mal mit dem Anwalt zu drohen.[/offtopic]

In LiveConfig können Sie den Socket auch explizit in der /etc/liveconfig/liveconfig.conf angeben. Fügen Sie dazu die Zeile "db_options = socket=/var/run/mysqld/mysql.sock" hinzu.

Wir werden dennoch gerne prüfen, ob es einen Workaround für diesen MySQL-Client-Fehler gibt.

Mit dem Eintrag des Parameters passt das nun (allerdings müssen die "" an andere Stellen)

Mit Version 1.9.0-r3619 enthält LiveConfig einen Workaround für den Bug im MySQL-Client.
LiveConfig (bzw. der darunterliegende Datenbank-Layer) initialisiert das mysql-Objekt dann für jeden Verbindungsversuch komplett neu.

Eventuell sind die hier vereinzelt genannten Sonderzeichen-Darstellungsfehler mit MySQL als Backend damit auch beseitigt (ich kann mir vorstellen, dass da beim Reconnect auch die UTF8-Einstellung verloren gegangen ist).