Pourquoi mariadb continue-t-il de mourir? Comment puis-je l'arrêter?
J'utilise MariaDB 10.0.23-0 sur Ubuntu 15.10 en tant que serveur LAMP. Exécuter Sudo /etc/init.d/mysql start entraîne:
Job for mariadb.service failed because a timeout was exceeded. See "systemctl status mariadb.service" and "journalctl -xe" for details.
Le résultat de systemctl status mariadb.service est:
● mariadb.service - serveur de base de données MariaDB Chargé: chargé (/lib/systemd/system/mariadb.service; activé; paramètre prédéfini par le fournisseur: activé) Drop-In:/etc/systemd/system/mariadb.service.d migrated-from-my.cnf-settings.conf Actif: en échec (Résultat: délai d'expiration) depuis le sam. 2016-03-26 22 : 52: 42 EDT; Il y a 26s Processus: 8707 ExecStart =/usr/sbin/mysqld $ MYSQLD_OPTS $ _WSREP_NEW_CLUSTER (code = quitté, status = 0/SUCCESS) Processus: 8706 ExecStartPre =/usr/bin - install m 755 -o mysql -g racine -d/var/run/mysqld (code = quitté, état = 0/SUCCESS) PID principal: 8707 (code = quitté, status = 0/SUCCESS) 26 mars 22:52:39 boggan systemd [1]: mariadb.service: l'opération de démarrage a expiré. Terminating. 26 mars 22:52:39 boggan mysqld [8707]: 2016-03-26 22:52:39 140105856617216 [Note]/usr/sbin/mysqld: Arrêt normal 26 mars 22:52:39 boggan mysqld [8707]: 2016-03-26 22:52:39 140105856617216 [Note] Planificateur d'événements - Purge de la file d'attente. 0 events 26 mars 22:52:39 boggan mysqld [8707]: 2016-03-26 22:52:39 140104920164096 [Note] InnoDB: FTS optimise la sortie de fil. 26 mars 22: 52:39 boggan mysqld [8707]: 2016-03-26 22:52:39 140105856617216 [Note] InnoDB: Début de l'arrêt ... 26 mars 22:52:42 boggan mysqld [8707]: 2016- 03-26 22:52:42 140105856617216 [Note] InnoDB: Arrêt terminé; numéro de séquence du journal 3336953 26 mars 22:52:42 boggan mysqld [8707]: 2016-03-26 22:52:42 140105856617216 [Note]/usr/sbin/mysqld: Arrêt complet 26 mars 22:52:42 boggan systemd [1]: Impossible de démarrer le serveur de base de données MariaDB. 26 mars 22:52:42 boggan systemd [1]: mariadb.service: l'unité est entrée en état d'échec. 26 mars 22:52:42 boggan systemd [1]: mariadb.service: Échec du résultat 'timeout'`
La première ligne systemd il y a une sorte de "bien duh". Je sais qu'il a expiré. Le second systemd, après les lignes mysqld est un peu mystificateur, car il démarre . Une application (OwnCloud, en particulier) qui dépend de la base de données fonctionne normalement ... à la minute près, MariaDB est en cours de modification.
ne autre question suggère d'utiliser time /etc/init.d/mysql start pour déterminer combien de temps cela prend. Je l'ai couru à plusieurs reprises pour confirmer l'heure - c'est quelques secondes de chaque côté de 90 secondes à chaque fois.
D'autres recherches m'amènent à vérifier les permissions sur les fichiers, ce qui est bien ... en plus, il démarre , temporairement. J'ai piqué au maximum de mes capacités (certes limitées en ce qui concerne Linux), et je n'ai pas progressé.
Donc, la question est ... Comment puis-je faire en sorte que le service MariaDB reste actif?
Comme une ride supplémentaire, après avoir écrit cette question, j’ai laissé la machine en marche. J'y suis revenu une semaine plus tard (je ne l'ai pas touché entre les deux). L'utilisation de la même commande, Sudo /etc/init.d/mysql start, a abouti. Le démon mysql a démarré et a fonctionné; il est revenu avec un rapport [ ok ]. J'ai redémarré pour des raisons d'expérimentation et je suis revenu à mon point de départ.
Si cela compte, le résultat de journalctl -xe est:
Apr 02 23:51:44 boggan systemd [1]: Arrêté Lire les fichiers requis à l'avance. - Objet: L'unité ureadahead.service a fini de s'arrêter - Défini -Par: systemd - Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel[.____.unset-- - L’unité ureadahead.service est terminée fermeture. avril 02 23:51:55 boggan mysqld [2645]: 2016-04-02 23:51:55 140386161068800 [Note] InnoDB: Online DDL: Début Avr 02 23: 51:55 boggan mysqld [2645]: 2016-04-02 23:51:55 140386161068800 [Note] InnoDB: DDL en ligne: lancez la lecture de l'index en cluster de la table et créez des fichiers temporaires 02 avr. 23:51: 55 boggan mysqld [2645]: 2016-04-02 23:51:55 140386161068800 [Note] InnoDB: DDL en ligne: fin de la lecture de l'index cluster de la table et création de fichiers temporaires Avril 02 23:51:55 boggan mysqld [2645]: 2016-04-02 23:51:55 140386161068800 [Note] InnoDB: DDL en ligne: Terminé 2 avril 23:51:55 boggan mysqld [2645]: 2016-04-02 23 : 51: 55 140386161068 800 [Note] InnoDB: DDL en ligne: Terminé 02 avr. 23:52:06 boggan dbus [713]: [système] Échec d'activation du service 'org.bluez': expiration du délai . Avr. 02 23:52:37 boggan systemd [1]: mariadb.service: l'opération de démarrage a expiré. Terminating. Apr 02 23:52:37 boggan mysqld [2645]: 2016-04-02 23:52:37 140386097400576 [Note]/usr/sbin/mysqld: Arrêt normal Avril 02 23:52:37 noyau boggan: audit: type = 1400 audit (1459655557.935: 31): apparmor = "DENIED" operation = "sendmsg" profile = "/ usr/sbin/mysqld" nom = "/ run/systemd/notify" pid = 2645 comm = "mysqld" wanted_mask = "w" denied_mask = "w" fsuid = 122 ouid = 0 2 avril 23:52:37 audit de boggan [2645]: AVC apparmor = "DENIED" operation = "sendmsg" profile = "/ usr/sbin/mysqld" name = "/ run/systemd/notify" pid = 2645 comm = "mysqld" wanted_mask = "w" denied_mask = "w" fsuid = 122 ouid = 0 2 avril 23:52:37 boggan mysqld [2645]: 2016-04-02 23:52:37 140386097400576 [Note] Planificateur d'événements: purge la file d'attente. 0 événements 02 avr. 23:52:37 boggan mysqld [2645]: 2016-04-02 23:52:37 140385225500416 [Note] InnoDB: FTS optimise la sortie du fil. Avril 02 23: 52:37 boggan mysqld [2645]: 2016-04-02 23:52:37 140386097400576 [Note] InnoDB: Démarrage de l'arrêt ... 02 avr. 23:52:39 boggan mysqld [2645]: 2016- 04-02 23:52:39 140386097400576 [Note] InnoDB: Arrêt terminé; numéro de séquence de log 3360838 02 avr. 23:52:39 boggan mysqld [2645]: 2016-04-02 23:52:39 140386097400576 [Note]/usr/sbin/mysqld: Arrêt complet 02 avril 23:52:39 noyau boggan: audit: type = 1400 audit (1459655559.419: 32): apparmor = "DENIED" operation = "sendmsg" profile = "/ usr/sbin/mysqld" nom = "/ run/systemd/notifier "pid = 2877 comm =" mysqld "wanted_mask =" w "denied_mask =" w "fsuid = 122 ouid = 0 2 avril 23:52:39 Audit boggan [2877]: AVC apparmor =" DENIED " operation = "sendmsg" profile = "/ usr/sbin/mysqld" nom = "/ run/systemd/notify" pid = 2877 comm = "mysqld" wanted_mask = "w" denied_mask = "w" fsuid = 122 ouid = 0 02 avr. 23:52:39 audit de boggan [2645]: AVC apparmor = "DENIED" operation = "sendmsg" profile = "/ usr/sbin/mysqld" nom = "/ run/systemd/notify" pid = 2645 comm = "mysqld" needed_mask = "w" denied_mask = "w" fsuid = 122 ouid = 0 02 avril 23:52:39 noyau boggan: audit: type = 1400 audit (1459655559.419: 33): apparmor = "DENIED" operation = "sendmsg" profile = "/ usr/sbin/mysqld" name = "/ run/systemd/notify" pid = 2645 comm = "mysqld" wanted_mask = "w" denied_mask = "w" fsuid = 122 ouid = 0 2 avril 23:52:39 boggan systemd [1]: Impossible de démarrer le serveur de base de données MariaDB. - Sujet: L'unité mariadb.service a échoué - Défini par: systemd - Assistance: http://lists.freedesktop.org/mailman/listinfo/systemd -niveau - - L'unité mariadb.service a échoué. - - Le résultat est un échec. Avril 02 23 : 52: 39 boggan systemd [1]: mariadb.service: l'unité est entrée en état d'échec. 02 avril 23:52:39 boggan systemd [1]: mariadb.service: a échoué avec le résultat 'timeout'. ____.]
apparmor était le coupable. Bien que le contenu de /etc/apparmor.d/usr.sbin.mysqld ne soit rien que des commentaires et prétende qu'il était là pour empêcher l'apparmeur d'étouffer MariaDB, c'est exactement ce qui se passait.
AppArmor et MySQL sur un blog Oracle fournit ce dont j'avais besoin pour comprendre ce qui se passait.
Sudo aa-status vous montre ce que fait apparmor; ce qui a réellement une politique appliquée, par rapport à ce qui vient de se plaindre.
Sudo apt-get install apparmor-utils ajoute quelques commandes qui facilitent le traitement des profils apparmor, telles que ...
Sudo aa-complain /usr/sbin/mysqld transforme le profil "enforce" en plainte. (aa-enforce le retourne.)
Une fois que c'est fait, Sudo service apparmor reload redémarre apparmor, et le tour est joué ... Sudo /etc/init.d/mysql start fonctionne et le serveur reste actif.
J'ai eu tout à fait le même problème après la mise à niveau de mysql à mariadb. La chose étrange est que service mariadb start a échoué après l'expiration du délai (soit au démarrage du système, soit manuellement), alors que le service mysql start a réussi.
L'explication donnée par T.J.L. est correcte mais la correction n'a pas fonctionné pour moi.
$ Sudo aa-complain /usr/sbin/mysqld
Setting /usr/sbin/mysqld to complain mode.
ERROR: /etc/apparmor.d/usr.sbin.mysqld contains no profile
J'ai donc désactivé le profil (avec aa-disable qui semble être équivalent à la solution de de plutocrate )
$ Sudo aa-disable /usr/sbin/mysqld
Disabling /usr/sbin/mysqld.
J'ai également désactivé mysqld-akonadi et mysqld-digikam.
Un rechargement d'appareil ne suffisait pas, alors j'ai dû redémarrer et mariadb a parfaitement démarré.
Je devais complètement désactiver mysql dans apparmor. Une plainte ne ferait rien pour moi. Alors ...
ln -s /etc/apparmor.d/usr.sbin.mysqld /etc/apparmor.d/disable/
Puis redémarrez
Une solution simple consiste à supprimer tout profil AppArmor inconnu:
aa-remove-unknown
Removing '/snap/core/6350/usr/lib/snapd/snap-confine'
Removing '/usr/sbin/mysqld'
Ça marche!
trois ans plus tard, votre solution est toujours valable! Merci!