Pourquoi mariadb continue de mourir? Comment puis-je l'arrêter?

25

J'utilise MariaDB 10.0.23-0 sur Ubuntu 15.10 en tant que serveur LAMP. sudo /etc/init.d/mysql startRésultats en cours d'exécution dans:

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

La sortie de systemctl status mariadb.serviceest:

● mariadb.service - serveur de base de données MariaDB
   Chargé: chargé (/lib/systemd/system/mariadb.service; activé; préréglage fournisseur: activé)
  Drop-In: /etc/systemd/system/mariadb.service.d
           └─migrated-from-my.cnf-settings.conf
   Actif: échoué (résultat: délai d'expiration) depuis sam. 2016-03-26 22:52:42 EDT; Il y a 26 ans
  Processus: 8707 ExecStart = / usr / sbin / mysqld $ MYSQLD_OPTS $ _WSREP_NEW_CLUSTER (code = quitté, statut = 0 / SUCCÈS)
  Processus: 8706 ExecStartPre = / usr / bin / install -m 755 -o mysql -g root -d / var / run / mysqld (code = exit, status = 0 / SUCCESS)
 PID principal: 8707 (code = sorti, statut = 0 / SUCCÈS)

26 mars 22:52:39 boggan systemd [1]: mariadb.service: le délai de démarrage de l'opération a expiré. Fin.
26 mars 22:52:39 boggan mysqld [8707]: 2016-03-26 22:52:39 140105856617216 [Remarque] / usr / sbin / mysqld: arrêt normal
26 mars 22:52:39 boggan mysqld [8707]: 2016-03-26 22:52:39 140105856617216 [Remarque] Planificateur d'événements: purge de la file d'attente. 0 événements
26 mars 22:52:39 boggan mysqld [8707]: 2016-03-26 22:52:39 140104920164096 [Remarque] InnoDB: FTS optimise la sortie du thread.
26 mars 22:52:39 boggan mysqld [8707]: 2016-03-26 22:52:39 140105856617216 [Note] InnoDB: Démarrage de l'arrêt ...
26 mars 22:52:42 boggan mysqld [8707]: 2016-03-26 22:52:42 140105856617216 [Remarque] InnoDB: arrêt terminé; journal numéro de séquence 3336953
26 mars 22:52:42 boggan mysqld [8707]: 2016-03-26 22:52:42 140105856617216 [Remarque] / usr / sbin / mysqld: arrêt terminé
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 avec le résultat 'timeout'`

La première systemdligne est une sorte de "bien duh". Je sais que ça a expiré. La seconde systemd, après les mysqldlignes est un peu déconcertant, car il fait en début de fait. Une application (OwnCloud, en particulier) qui dépend de la base de données fonctionne normalement ... pendant la minute et le changement de MariaDB.

Une autre question a suggéré d'utiliser time /etc/init.d/mysql startpour déterminer combien de temps cela prenait. Je l'ai couru à plusieurs reprises pour confirmer l'heure - c'est à chaque fois quelques secondes de chaque côté des années 90.

D' autres recherches me conduisent à vérifier les autorisations de fichiers, qui sont très bien ... D' ailleurs, il ne démarre, temporairement. J'ai poussé et poussé au mieux de mes capacités (certes limitées en ce qui concerne Linux), et je n'ai fait aucun progrès.

Alors, la question est ... Comment faire pour que le service MariaDB reste actif?

Comme 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 exacte,, sudo /etc/init.d/mysql starta réussi. Le démon mysql a démarré et s'est exécuté; il est revenu avec un [ ok ]rapport. J'ai redémarré pour des raisons d'expérimentation, et je suis de retour là où j'ai commencé.

Si cela est important, la sortie de journalctl -xeest:

02 avr 23:51:44 boggan systemd [1]: Arrêt de la lecture des fichiers requis à l'avance.
- Objet: L'unité ureadahead.service a terminé sa fermeture
- Défini par: systemd
- Prise en charge: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
- 
- L'unité ureadahead.service a terminé sa fermeture.
02 avr 23:51:55 boggan mysqld [2645]: 2016-04-02 23:51:55 140386161068800 [Remarque] InnoDB: DDL en ligne: Démarrer
02 avr 23:51:55 boggan mysqld [2645]: 2016-04-02 23:51:55 140386161068800 [Remarque] InnoDB: DDL en ligne: commencez à lire l'index 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 [Remarque] InnoDB: DDL en ligne: Fin de la lecture de l'index cluster de la table et création de fichiers temporaires
02 avr 23:51:55 boggan mysqld [2645]: 2016-04-02 23:51:55 140386161068800 [Remarque] InnoDB: DDL en ligne: terminé
02 avr 23:51:55 boggan mysqld [2645]: 2016-04-02 23:51:55 140386161068800 [Remarque] InnoDB: DDL en ligne: terminé
02 avr 23:52:06 boggan dbus [713]: [système] Échec de l'activation du service 'org.bluez': délai dépassé
02 avr 23:52:37 boggan systemd [1]: mariadb.service: le délai de démarrage a expiré. Fin.
02 avr 23:52:37 boggan mysqld [2645]: 2016-04-02 23:52:37 140386097400576 [Remarque] / usr / sbin / mysqld: arrêt normal
02 avr 23:52:37 noyau boggan: audit: type = 1400 audit (1459655557.935: 31): apparmor = "REFUSÉ" operation = "sendmsg" profile = "/ usr / sbin / mysqld" name = "/ run / systemd / notifier "pid = 2645 comm =" mysqld "demandé_mask =" w "refusé_mask =" w "fsuid = 122 ouid = 0
02 avr 23:52:37 audit boggan [2645]: AVC apparmor = "DENIED" operation = "sendmsg" profile = "/ usr / sbin / mysqld" name = "/ run / systemd / notify" pid = 2645 comm = " mysqld "demandé_mask =" w "refusé_mask =" w "fsuid = 122 ouid = 0
02 avril 23:52:37 boggan mysqld [2645]: 2016-04-02 23:52:37 140386097400576 [Remarque] Planificateur d'événements: purge de la file d'attente. 0 événements
02 avr 23:52:37 boggan mysqld [2645]: 2016-04-02 23:52:37 140385225500416 [Remarque] InnoDB: FTS optimise la sortie du thread.
02 avr 23:52:37 boggan mysqld [2645]: 2016-04-02 23:52:37 140386097400576 [Remarque] InnoDB: Démarrage de l'arrêt ...
02 avril 23:52:39 boggan mysqld [2645]: 2016-04-02 23:52:39 140386097400576 [Remarque] InnoDB: arrêt terminé; numéro de séquence du journal 3360838
02 avr 23:52:39 boggan mysqld [2645]: 2016-04-02 23:52:39 140386097400576 [Remarque] / usr / sbin / mysqld: arrêt terminé
02 avr 23:52:39 noyau boggan: audit: type = 1400 audit (1459655559.419: 32): apparmor = "REFUSÉ" operation = "sendmsg" profile = "/ usr / sbin / mysqld" name = "/ run / systemd / notifier "pid = 2877 comm =" mysqld "demandé_mask =" w "refusé_mask =" w "fsuid = 122 ouid = 0
02 avr 23:52:39 audit boggan [2877]: AVC apparmor = "DENIED" operation = "sendmsg" profile = "/ usr / sbin / mysqld" name = "/ run / systemd / notify" pid = 2877 comm = " mysqld "demandé_mask =" w "refusé_mask =" w "fsuid = 122 ouid = 0
02 avr 23:52:39 audit boggan [2645]: AVC apparmor = "DENIED" operation = "sendmsg" profile = "/ usr / sbin / mysqld" name = "/ run / systemd / notify" pid = 2645 comm = " mysqld "demandé_mask =" w "refusé_mask =" w "fsuid = 122 ouid = 0
02 avr 23:52:39 noyau boggan: audit: type = 1400 audit (1459655559.419: 33): apparmor = "REFUSÉ" operation = "sendmsg" profile = "/ usr / sbin / mysqld" name = "/ run / systemd / notifier "pid = 2645 comm =" mysqld "demandé_mask =" w "refusé_mask =" w "fsuid = 122 ouid = 0
02 avr 23:52:39 boggan systemd [1]: échec du démarrage du serveur de base de données MariaDB.
- Objet: échec de l'unité mariadb.service
- Défini par: systemd
- Prise en charge: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
- 
- L'unité mariadb.service a échoué.
- 
- Le résultat a échoué.
02 avr 23:52:39 boggan systemd [1]: mariadb.service: L'unité est entrée en état d'échec.
02 avr 23:52:39 boggan systemd [1]: mariadb.service: échec avec le résultat 'timeout'.
TJL
la source
2
La journalctl -xesortie est tronquée, pouvez-vous la mettre à jour? apparmor="DENIED"Examinez de plus près les messages (si l'apparmeur est activé sur votre système d'exploitation) car cela pourrait être un problème lors du démarrage de mariadb.
jusqu'au
@tlo je le ferai ... il faudra juste attendre ce soir. Je n'ai pas accès à la machine d'où je suis. Après tout, je ne pouvais pas le faire fonctionner lorsque j'étais assis, alors pourquoi prendre la peine de le configurer pour un accès à distance. Je vais certainement regarder dans l'apparmeur aussi. S'il était activé, il était activé par défaut. Je n'ai rien changé installé par le système, j'ai juste ajouté le truc LAMP.
TJL
@tlo Mise à jour de la sortie et ajout d'un petit pli à la description. Au lieu de frapper dessus, je vais m'en aller pendant une heure ou deux, et voir ce qui se passe ...
TJL
1
@tlo Merci pour l'aide. l'apparmeur était le coupable.
TJL

Réponses:

28

J'ai eu le même problème après la mise à niveau de mysql vers mariadb. Ce qui est étrange, c'est que le démarrage du service mariadb a échoué lors de la temporisation (au démarrage du système ou manuellement) alors que le démarrage du service mysql a réussi.

L'explication donnée par TJL est juste 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 ploutocrate )

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

J'ai également désactivé mysqld-akonadi et mysqld-digikam.

Un rechargement d'apparmeur ne suffisait pas, j'ai donc dû redémarrer et mariadb a parfaitement démarré.

ChrisAga
la source
Confirmer qu'il n'a pas pu trouver un moyen de le faire fonctionner sans redémarrer.
Meetai.com
Cette réponse a fonctionné pour moi sur Kubuntu 18.04.2 LTS. complainet ... apparmor reload( réponse TJL ) n'était en effet pas suffisant.
Marten Koetsier
25

l'apparmeur était le coupable. Malgré le contenu de /etc/apparmor.d/usr.sbin.mysqldn'être que des commentaires et de prétendre qu'il était là pour que l'apparmeur ne s'étouffe pas avec MariaDB, c'est exactement ce qui se passait.

AppArmor et MySQL sur un blog Oracle ont fourni ce dont j'avais besoin pour comprendre ce qui se passait.

sudo aa-statusvous montre ce que fait l'apparmeur; 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 la gestion des profils d'apparmeur, comme ...

sudo aa-complain /usr/sbin/mysqldtransforme le profil de «appliquer» à se plaindre. (aa-enforce le retourne.)

Une fois cela fait, sudo service apparmor reloadredémarre l'apparmor, et le tour est joué ... sudo /etc/init.d/mysql startet le serveur reste en place.

TJL
la source
1
Mec de merde; qui a réellement fonctionné. J'ai eu une légère panique car cela a affecté notre serveur de production, le laissant en panne pendant quelques heures. Je ne suis pas un expert comme vous et j'ai recherché sur le Web diverses erreurs dans le fichier /var/log/mysql/error.log. Merci beaucoup pour ça!
Muqito
1
Pareil pour moi. J'ai mis à jour Ubuntu 14.04 vers 16.04 et j'ai perdu la possibilité d'exécuter MySQL. Maintenant ça marche! Merci beaucoup d'avoir détaillé ceci: D. Je cherche depuis des semaines!
Sawtaytoes
Ne le fait pas tout à fait pour moi, mais merci pour le conseil avec apparmor-utils. Trois ans plus tard, je reçois ERROR: /etc/apparmor.d/usr.sbin.mysqld contains no profile.
YetiCGN
14

J'ai dû désactiver complètement mysql dans apparmor. Un aa-plainte ne ferait rien pour moi. Alors ...

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

Redémarrez ensuite

ploutocrate
la source
Merci! C'était la seule solution à mon problème! Je suis également passé de mysql à mariadb
Thomas Gatt
c'est aussi ce qui a fonctionné pour moi, merci beaucoup
Eman
3

Une solution simple consiste à supprimer tous les profils AppArmor inconnus:

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

Ça marche!

Loc Luong
la source
C'était en fait ce que je devais faire pour faire fonctionner les choses, alors merci. La réponse acceptée ci-dessus me donnerait ERROR: /etc/apparmor.d/usr.sbin.mysqld contains no profilecomme c'est exactement vrai, étant donné que le fichier ne contient que des commentaires. Peut-être que dans une version plus récente d'AppArmor, ils l'ont mis en échec avec ces fichiers, alors qu'il fonctionnait en 2016.
YetiCGN
C'est la bonne réponse (au moins en 2019). Ce qui se passe, c'est qu'après la désinstallation de MySql, le profil AppArmor pour /usr/sbin/mysqldest toujours chargé dans le noyau. L'exécution aa-remove-unknown(ou le redémarrage) résout ce problème.
zwets