Warum stirbt Mariadb weiter? Wie höre ich damit auf?

Ich verwende MariaDB 10.0.23-0 auf Ubuntu 15.10 als LAMP-Server. Laufende sudo /etc/init.d/mysql startErgebnisse in:

Job for mariadb.service failed because a timeout was exceeded. See "systemctl status mariadb.service" and "journalctl -xe" for details.

Die Ausgabe von systemctl status mariadb.serviceist:

● mariadb.service - MariaDB-Datenbankserver
   Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; Herstellervoreinstellung: enabled)
  Drop-In: /etc/systemd/system/mariadb.service.d
           └─migriert-von-my.cnf-settings.conf
   Aktiv: fehlgeschlagen (Ergebnis: Timeout) seit Sa 2016-03-26 22:52:42 EDT; Vor 26s
  Prozess: 8707 ExecStart = / usr / sbin / mysqld $ MYSQLD_OPTS $ _WSREP_NEW_CLUSTER (Code = beendet, Status = 0 / SUCCESS)
  Prozess: 8706 ExecStartPre = / usr / bin / install -m 755 -o mysql -g root -d / var / run / mysqld (Code = beendet, Status = 0 / SUCCESS)
 Haupt-PID: 8707 (Code = Verlassen, Status = 0 / ERFOLG)

26. März, 22:52:39 Uhr, Rodelsystem [1]: mariadb.service: Zeitüberschreitung beim Start des Betriebs. Beenden.
26. März 22:52:39 boggan mysqld [8707]: 2016-03-26 22:52:39 140105856617216 [Anmerkung] / usr / sbin / mysqld: Normales Herunterfahren
26. März 22:52:39 boggan mysqld [8707]: 2016-03-26 22:52:39 140105856617216 [Hinweis] Event Scheduler: Löschen der Warteschlange. 0 Ereignisse
26. März 22:52:39 boggan mysqld [8707]: 2016-03-26 22:52:39 140104920164096 [Anmerkung] InnoDB: FTS optimiert das Beenden des Threads.
26. März 22:52:39 boggan mysqld [8707]: 2016-03-26 22:52:39 140105856617216 [Anmerkung] InnoDB: Herunterfahren wird gestartet ...
26. März 22:52:42 boggan mysqld [8707]: 2016-03-26 22:52:42 140105856617216 [Anmerkung] InnoDB: Herunterfahren abgeschlossen; Protokollfolgenummer 3336953
26. März 22:52:42 boggan mysqld [8707]: 2016-03-26 22:52:42 140105856617216 [Anmerkung] / usr / sbin / mysqld: Herunterfahren abgeschlossen
26. März 22:52:42 boggan systemd [1]: MariaDB-Datenbankserver konnte nicht gestartet werden.
26. März, 22:52:42 Uhr Schlupfanlage [1]: mariadb.service: Die Einheit ist in den Status "Fehler" eingetreten.
26. März, 22:52:42 Uhr, Schlupfanlage [1]: mariadb.service: Fehler mit dem Ergebnis "Timeout"

Die erste systemdZeile dort ist eine Art "gut duh". Ich weiß, dass die Zeit abgelaufen ist. Die zweite systemd, nach den mysqldLinien ist ein bisschen rätselhaft, denn es tut in der Tat Anfang. Eine Anwendung (speziell OwnCloud), die von der Datenbank abhängt, funktioniert normal ... für die Minute und die Änderung, die MariaDB ausführt.

Eine andere Frage schlug vor, anhand time /etc/init.d/mysql startderer ermittelt werden sollte, wie lange es gedauert hat. Ich habe es wiederholt ausgeführt, um die Uhrzeit zu bestätigen - es sind jeweils ein paar Sekunden zu beiden Seiten der 90er.

Weitere Forschung führte mich Dateiberechtigungen zu überprüfen, was in Ordnung ist ... außerdem ist es nicht starten, vorübergehend. Ich habe nach Kräften gestochert und mich nach besten Kräften um Linux gekümmert und bin noch nicht weitergekommen.

Die Frage ist also ... Wie kann ich den MariaDB-Dienst dazu bringen, auf dem Laufenden zu bleiben?

Nachdem ich diese Frage geschrieben hatte, ließ ich die Maschine laufen. Ich bin eine Woche später darauf zurückgekommen (ich habe es dazwischen nicht angefasst). Die Verwendung des exakt gleichen Befehls sudo /etc/init.d/mysql startwar erfolgreich. Der MySQL-Daemon wurde gestartet und ausgeführt. es kam mit einem [ ok ]Bericht zurück. Ich habe zum Experimentieren einen Neustart durchgeführt und bin wieder da, wo ich angefangen habe.

Falls es darauf ankommt, ist die Ausgabe von journalctl -xe:

Apr 02 23:51:44 boggan systemd [1]: Gestoppt Erforderliche Dateien vorab lesen.
- Betreff: Einheit ureadahead.service wurde heruntergefahren
- Definiert von: systemd
- Unterstützung: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
- 
- Das Gerät ureadahead.service wurde heruntergefahren.
Apr 02 23:51:55 boggan mysqld [2645]: 2016-04-02 23:51:55 140386161068800 [Anmerkung] InnoDB: Online DDL: Start
Apr 02 23:51:55 boggan mysqld [2645]: 2016-04-02 23:51:55 140386161068800 [Anmerkung] InnoDB: Online-DDL: Beginnen Sie mit dem Lesen des Clustered-Index der Tabelle und erstellen Sie temporäre Dateien
Apr 02 23:51:55 boggan mysqld [2645]: 2016-04-02 23:51:55 140386161068800 [Anmerkung] InnoDB: Online-DDL: Ende des Lesens des Clustered-Index der Tabelle und Erstellen temporärer Dateien
Apr 02 23:51:55 boggan mysqld [2645]: 2016-04-02 23:51:55 140386161068800 [Hinweis] InnoDB: Online-DDL: Abgeschlossen
Apr 02 23:51:55 boggan mysqld [2645]: 2016-04-02 23:51:55 140386161068800 [Hinweis] InnoDB: Online-DDL: Abgeschlossen
Apr 02 23:52:06 boggan dbus [713]: [system] Dienst 'org.bluez' konnte nicht aktiviert werden: Zeitüberschreitung
Apr 02 23:52:37 boggan systemd [1]: mariadb.service: Zeitüberschreitung beim Start des Betriebs. Beenden.
Apr 02 23:52:37 boggan mysqld [2645]: 2016-04-02 23:52:37 140386097400576 [Hinweis] / usr / sbin / mysqld: Normales Herunterfahren
Apr 02 23:52:37 boggan kernel: audit: type = 1400 audit (1459655557.935: 31): apparmor = "DENIED" operation = "sendmsg" profile = "/ usr / sbin / mysqld" name = "/ run / systemd / Benachrichtigen Sie "pid = 2645 comm =" mysqld "request_mask =" w "denied_mask =" w "fsuid = 122 ouid = 0
Apr 02 23:52:37 Fehlerprüfung [2645]: AVC apparmor = "DENIED" operation = "sendmsg" profile = "/ usr / sbin / mysqld" name = "/ run / systemd / notify" pid = 2645 comm = " mysqld "required_mask =" w "denied_mask =" w "fsuid = 122 ouid = 0
Apr 02 23:52:37 boggan mysqld [2645]: 2016-04-02 23:52:37 140386097400576 [Hinweis] Ereignisplanung: Löschen der Warteschlange. 0 Ereignisse
Apr 02 23:52:37 boggan mysqld [2645]: 2016-04-02 23:52:37 140385225500416 [Anmerkung] InnoDB: FTS-Optimierung, Thread wird beendet.
Apr 02 23:52:37 boggan mysqld [2645]: 2016-04-02 23:52:37 140386097400576 [Anmerkung] InnoDB: Herunterfahren wird gestartet ...
Apr 02 23:52:39 boggan mysqld [2645]: 2016-04-02 23:52:39 140386097400576 [Hinweis] InnoDB: Herunterfahren abgeschlossen; Protokollfolgenummer 3360838
Apr 02 23:52:39 boggan mysqld [2645]: 2016-04-02 23:52:39 140386097400576 [Hinweis] / usr / sbin / mysqld: Herunterfahren abgeschlossen
Apr 02 23:52:39 boggan kernel: audit: type = 1400 audit (1459655559.419: 32): apparmor = "DENIED" operation = "sendmsg" profile = "/ usr / sbin / mysqld" name = "/ run / systemd / Benachrichtigen Sie "pid = 2877 comm =" mysqld "request_mask =" w "denied_mask =" w "fsuid = 122 ouid = 0
Apr 02 23:52:39 Fehlerprüfung [2877]: AVC apparmor = "DENIED" operation = "sendmsg" profile = "/ usr / sbin / mysqld" name = "/ run / systemd / notify" pid = 2877 comm = " mysqld "required_mask =" w "denied_mask =" w "fsuid = 122 ouid = 0
Apr 02 23:52:39 Fehlerprüfung [2645]: AVC apparmor = "DENIED" operation = "sendmsg" profile = "/ usr / sbin / mysqld" name = "/ run / systemd / notify" pid = 2645 comm = " mysqld "required_mask =" w "denied_mask =" w "fsuid = 122 ouid = 0
Apr 02 23:52:39 boggan kernel: audit: type = 1400 audit (1459655559.419: 33): apparmor = "DENIED" operation = "sendmsg" profile = "/ usr / sbin / mysqld" name = "/ run / systemd / Benachrichtigen Sie "pid = 2645 comm =" mysqld "request_mask =" w "denied_mask =" w "fsuid = 122 ouid = 0
Apr 02 23:52:39 boggan systemd [1]: MariaDB-Datenbankserver konnte nicht gestartet werden.
- Betreff: Einheit mariadb.service ist ausgefallen
- Definiert von: systemd
- Unterstützung: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
- 
- Einheit mariadb.service ist ausgefallen.
- 
- Das Ergebnis ist fehlgeschlagen.
Apr 02 23:52:39 boggan systemd [1]: mariadb.service: Das Gerät ist in einen fehlerhaften Zustand übergegangen.
Apr 02 23:52:39 boggan systemd [1]: mariadb.service: Fehler mit dem Ergebnis 'timeout'.

Ich hatte nach dem Upgrade von MySQL auf Mariadb das gleiche Problem. Das Seltsame war, dass der Start von Service-Mariadb beim Timeout fehlgeschlagen ist (entweder beim Systemstart oder manuell), während der Start von Service-MySQL erfolgreich war.

Die Erklärung von TJL ist richtig, aber die Korrektur hat bei mir nicht funktioniert.

$ sudo aa-complain /usr/sbin/mysqld
Setting /usr/sbin/mysqld to complain mode.

ERROR: /etc/apparmor.d/usr.sbin.mysqld contains no profile

Also habe ich das Profil deaktiviert (mit aa-disable, was der Lösung von plutocrat zu entsprechen scheint )

$ sudo aa-disable /usr/sbin/mysqld
Disabling /usr/sbin/mysqld.

Ich habe auch mysqld-akonadi und mysqld-digikam deaktiviert.

Ein Apparmor-Reload war nicht genug, also musste ich neu starten und Mariadb startete perfekt.

apparmor war der Schuldige. Trotz des Inhalts /etc/apparmor.d/usr.sbin.mysqld, nichts als Kommentare zu sein und zu behaupten, dass es da war, damit der Apparat MariaDB nicht verschluckt, passierte genau das.

AppArmor und MySQL in einem Oracle-Blog lieferten alles, was ich brauchte, um herauszufinden, was los war.

sudo aa-statuszeigt dir was apparmor macht; Was hat eigentlich eine erzwungene Richtlinie im Vergleich zu dem, was nur beschweren soll.

sudo apt-get install apparmor-utils fügt ein paar Befehle hinzu, die die Handhabung der AppArmor-Profile erleichtern, z. B. ...

sudo aa-complain /usr/sbin/mysqldSchaltet das Profil von "erzwingen" auf Beschwerde. ( aa-enforcedreht es zurück.)

Sobald dies erledigt ist, sudo service apparmor reloadstartet apparmor neu und voila ... sudo /etc/init.d/mysql startfunktioniert und der Server bleibt in Betrieb.

Ich musste mysql in apparmor komplett deaktivieren. Eine Beschwerde würde nichts für mich tun. So ...

ln -s /etc/apparmor.d/usr.sbin.mysqld /etc/apparmor.d/disable/

Starten Sie dann neu

Eine einfache Lösung besteht darin, unbekannte AppArmor-Profile zu entfernen:

aa-remove-unknown
Removing '/snap/core/6350/usr/lib/snapd/snap-confine'
Removing '/usr/sbin/mysqld'

Es klappt!