MariaDB stützt ab - Failed to start with customized my.cnf

[mexx81]

Hallo,

aus mir unbekannten Gründen stützt der MariaDB Dienst ab und ermöglicht keinen Zugriff auf die Datenbanken. Die Fehlermeldung beim Versuch Ihn zu starten lautet "Failed to start with customized my.cnf, restart with default configuration."

Es gibt keine angepasste my.cnf und der restart mit default ist ebenfalls nicht erfolgeich. Die Lösung des Problems habe ich bereits. Man muss unter \volume1\@database\mysql die Logfiles löschen. Dann läßt sich der Dienst wieder starten.

Da das Problem jedoch bereits zwei mal passierte, möchte ich nun eine dauerhafte Lösung haben. Ich vermute, dass das Logfile zu groß wird, also könnte eine Lösung sein, die maximale Größe zu erhöhen. Ich vermute mal in der my.cnf. Bevor ich jedoch blind solche Eingriffe vornehme, möchte ich eure Meinung dazu lesen.

Vielen Dank,
mexx

 

[flingo]

Mir geht's ähnlich, allerdings sind wir fast ein Jahr weiter und ich vermute ein Problem mit bei DSM 6 Update 2, welches ich kurz vorher installiert hatte.

Logfiles löschen half nicht.

Ablauf:
- DSM 6 Update installiert
- DSM zeigt konstant eine CPU-Last von ca. 90 % an
- also Reboot der Maschine über shell
- danach kommt MariaDB mit o.g. Meldung nicht mehr hoch

Nach 2 Abenden habe ich jetzt eine leider wenig nachhaltige Methode gefunden, wie ich die MariaDB wieder starten kann. Die vermutliche Ursache findet man in

/volume1/@database/mysql/DiskStation.err:
160420 21:13:34 [ERROR] mysqld: Can't create/write to file '/tmp/ibCGumXo' (Errcode: 13)
160420 21:13:34 InnoDB: Error: unable to create temporary file; errno: 13​

Und in der Tat, wenn man mal

ls -ld /tmp​

macht, sieht man, dass dem Verzeichnis das Sticky-Bit fehlt. Das Sticky-Bit muss bei /tmp aber gesetzt sein, damit beliebige user (MariaDB läuft als user mysql) dort temporäre Dateien anlegen können. Wenn man nun das Naheliegende macht:

chmod 1777 /tmp/​

behebt man die vermeintliche Ursache und MariaDB startet wieder. Blöderweise ist dann aber die DSM-Oberfläche (und AudioStation) irgendwann nicht mehr erreichbar.(Sorry, the page you are looking for is not found.): Operation gelungen, Patient tot! Offensichtlich will die DSM sowas nicht, ein Zurückändern hilft auch nicht, erst nach Reboot ist die DSM-Oberfläche wieder erreichbar, das Sticky-Bit wieder zurück gesetzt und MariaDB wieder nicht hochgekommen.

Ich würde ja gerne MariaDB deinstallieren und neu installieren, aber da ist noch eine ownCloud, die ich nicht deinstalliert bekomme und davon ist die MariaDB abhängig ...

Ich bin dankbar für jeden Hinweis, der nicht auf Neuinstallation der Diskstation hinausläuft!

Martin

Edit:
Was soll ich sagen: kaum, dass ich das geschrieben habe, hat sich was geändert: nach dem letzten Reboot (wg. DSM-Oberfläche nicht mehr erreichbar), hat /tmp das Sticky-Bit behalten, MariaDB ist hochgekommen und die DSM-Weboberfläche ist auch erreichbar. Auch ist meine owncloud-Reparatur ein Stück weiter gekommen, allerdings funktioniert die Einrichtung der Datenbank nicht, aber das ist scheinbar ein anderes Problem mit einem anderen Thread...

 

[flingo]

Exiftool (Beta) Package Installer verbiegt die Zugriffsrechte auf /tmp

Die Zugriffsrechte auf /tmp scheinen wirklich das Problem zu sein. Kann mir mal einer bestätigen, dass auf seiner Diskstation die Zugriffsrechte auf /tmp wie folgt aussehen:

root@DiskStation:~# ls -ld /tmp
drwxrwxrwt 15 root root 1400 Apr 21 19:26 /tmp

Was ich gestern nicht erwähnt habe, war die Installation vom Exiftool(Beta) Paket, weil es ja eigentlich nichts mit der Sache zu tun hat, dachte ich. Ich habe es gestern mal angehalten und dann ging es ja. Heute habe ich es nochmal gestartet, und siehe da, ohne mein Zutun wurde die Zugriffsrechte wieder zurück gesetzt.

root@DiskStation:~# chmod 1777 /tmp
root@DiskStation:~# ls -ld /tmp
drwxrwxrwt 15 root root 1400 Apr 21 19:26 /tmp
root@DiskStation:~# ls -ld /tmp
drwxr-xr-x 15 root root 1420 Apr 21 19:26 /tmp

Hab's noch 2-mal getestet. Der Installer ist der Übeltäter! Ich werde ihm mal ein Bug-Report schicken.

 

[goetz]

Hallo,
kann für DSM 5.2 und 6.0
drwxrwxrwt 15 root root 1780 2016-04-21 18:22 /tmp
bestätigen.

Gruß Götz

 

[flingo]

Cool, Danke!

Dann passt das so.

Grüß, Martin