¿Por qué sigue muriendo mariadb? ¿Como lo detengo?

25

Estoy ejecutando MariaDB 10.0.23-0 en Ubuntu 15.10 como servidor LAMP. sudo /etc/init.d/mysql startResultados en ejecución en:

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

La salida de systemctl status mariadb.servicees:

● mariadb.service: servidor de bases de datos MariaDB
   Cargado: cargado (/lib/systemd/system/mariadb.service; habilitado; proveedor preestablecido: habilitado)
  Drop-In: /etc/systemd/system/mariadb.service.d
           └─migrated-from-my.cnf-settings.conf
   Activo: fallido (Resultado: tiempo de espera) desde el sábado 2016-03-26 22:52:42 EDT; Hace 26s
  Proceso: 8707 ExecStart = / usr / sbin / mysqld $ MYSQLD_OPTS $ _WSREP_NEW_CLUSTER (código = salido, estado = 0 / ÉXITO)
  Proceso: 8706 ExecStartPre = / usr / bin / install -m 755 -o mysql -g root -d / var / run / mysqld (código = salido, estado = 0 / ÉXITO)
 PID principal: 8707 (código = salido, estado = 0 / ÉXITO)

26 de marzo 22:52:39 boggan systemd [1]: mariadb.service: la operación de inicio ha excedido el tiempo de espera. Terminando.
26 de marzo 22:52:39 boggan mysqld [8707]: 2016-03-26 22:52:39 140105856617216 [Nota] / usr / sbin / mysqld: apagado normal
26 de marzo 22:52:39 boggan mysqld [8707]: 2016-03-26 22:52:39 140105856617216 [Nota] Programador de eventos: Purga de la cola. 0 eventos
26 de marzo 22:52:39 boggan mysqld [8707]: 2016-03-26 22:52:39 140104920164096 [Nota] InnoDB: FTS optimiza la salida del hilo.
26 de marzo 22:52:39 boggan mysqld [8707]: 2016-03-26 22:52:39 140105856617216 [Nota] InnoDB: Iniciando el apagado ...
26 de marzo 22:52:42 boggan mysqld [8707]: 2016-03-26 22:52:42 140105856617216 [Nota] InnoDB: Apagado completado; número de secuencia de registro 3336953
26 de marzo 22:52:42 boggan mysqld [8707]: 2016-03-26 22:52:42 140105856617216 [Nota] / usr / sbin / mysqld: apagado completo
26 de marzo 22:52:42 boggan systemd [1]: Error al iniciar el servidor de base de datos MariaDB.
26 de marzo 22:52:42 boggan systemd [1]: mariadb.service: la unidad entró en estado fallido.
26 de marzo 22:52:42 boggan systemd [1]: mariadb.service: Error con el resultado 'tiempo de espera' '

La primera systemdlínea allí es una especie de "bien duh". Sé que se agotó el tiempo. El segundo systemd, después de que las mysqldlíneas es una desconcertante poco, ya que lo hace en el hecho de inicio. Una aplicación (OwnCloud, específicamente) que depende de la base de datos funciona normalmente ... por el minuto y el cambio que está funcionando MariaDB.

Otra pregunta sugirió usar time /etc/init.d/mysql startpara determinar cuánto tiempo estaba tomando. Lo ejecuté repetidamente para confirmar la hora: cada segundo son unos segundos a cada lado de los 90.

Otras investigaciones me llevan a comprobar los permisos de archivos, que son bien ... además, no puesta en marcha, de manera temporal. He tocado y empujado a lo mejor de mi capacidad (ciertamente limitada cuando se trata de Linux), y no he avanzado.

Entonces, la pregunta es ... ¿Cómo hago para que el servicio MariaDB permanezca despierto?

Como una arruga adicional, después de escribir esta pregunta, dejé la máquina en funcionamiento. Volví a eso una semana más tarde (no lo toqué). Usar exactamente el mismo comando sudo /etc/init.d/mysql start, fue exitoso. El demonio mysql comenzó y corrió; volvió con un [ ok ]informe. Reinicié por el bien de la experimentación, y estoy de vuelta donde comencé.

En caso de que sea importante, la salida de journalctl -xees:

02 de abril 23:51:44 boggan systemd [1]: Detenido Leer los archivos requeridos por adelantado.
- Asunto: la unidad ureadahead.service ha terminado de apagarse
- Definido por: systemd
- Soporte: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
- 
- La unidad ureadahead.service ha terminado de apagarse.
02 de abril 23:51:55 boggan mysqld [2645]: 02/04/2016 23:51:55 140386161068800 [Nota] InnoDB: DDL en línea: Inicio
02 de abril 23:51:55 boggan mysqld [2645]: 02/04/2016 23:51:55 140386161068800 [Nota] InnoDB: DDL en línea: comience a leer el índice agrupado de la tabla y cree archivos temporales
02 de abril 23:51:55 boggan mysqld [2645]: 02/04/2016 23:51:55 140386161068800 [Nota] InnoDB: DDL en línea: Fin de leer el índice agrupado de la tabla y crear archivos temporales
02 de abril 23:51:55 boggan mysqld [2645]: 02/04/2016 23:51:55 140386161068800 [Nota] InnoDB: DDL en línea: completado
02 de abril 23:51:55 boggan mysqld [2645]: 02/04/2016 23:51:55 140386161068800 [Nota] InnoDB: DDL en línea: completado
02 de abril 23:52:06 boggan dbus [713]: [sistema] Error al activar el servicio 'org.bluez': se agotó el tiempo de espera
02 de abril 23:52:37 boggan systemd [1]: mariadb.service: la operación de inicio ha expirado. Terminando.
02 de abril 23:52:37 boggan mysqld [2645]: 02/04/2016 23:52:37 140386097400576 [Nota] / usr / sbin / mysqld: apagado normal
02 de abril 23:52:37 kernel boggan: auditoría: tipo = 1400 auditoría (1459655557.935: 31): apparmor = "DENIED" operation = "sendmsg" profile = "/ usr / sbin / mysqld" name = "/ run / systemd / notifique "pid = 2645 comm =" mysqld "solicitado_mask =" w "negar_mask =" w "fsuid = 122 ouid = 0
02 de abril 23:52:37 auditoría boggan [2645]: AVC apparmor = "DENIED" operación = "sendmsg" profile = "/ usr / sbin / mysqld" name = "/ run / systemd / notify" pid = 2645 comm = " mysqld "required_mask =" w "deny_mask =" w "fsuid = 122 ouid = 0
02 de abril 23:52:37 boggan mysqld [2645]: 02/04/2016 23:52:37 140386097400576 [Nota] Programador de eventos: Purga de la cola. 0 eventos
02 de abril 23:52:37 boggan mysqld [2645]: 02/04/2016 23:52:37 140385225500416 [Nota] InnoDB: FTS optimiza la salida del hilo.
02 de abril 23:52:37 boggan mysqld [2645]: 02/04/2016 23:52:37 140386097400576 [Nota] InnoDB: Inicio del apagado ...
02 de abril 23:52:39 boggan mysqld [2645]: 02/04/2016 23:52:39 140386097400576 [Nota] InnoDB: cierre completado; número de secuencia de registro 3360838
02 de abril 23:52:39 boggan mysqld [2645]: 02/04/2016 23:52:39 140386097400576 [Nota] / usr / sbin / mysqld: apagado completo
02 de abril 23:52:39 kernel de boggan: auditoría: tipo = 1400 auditoría (1459655559.419: 32): apparmor = "DENIED" operation = "sendmsg" profile = "/ usr / sbin / mysqld" name = "/ run / systemd / notifique "pid = 2877 comm =" mysqld "solicitado_mask =" w "negar_mask =" w "fsuid = 122 ouid = 0
02 de abril 23:52:39 auditoría boggan [2877]: AVC apparmor = "DENIED" operación = "sendmsg" profile = "/ usr / sbin / mysqld" name = "/ run / systemd / notify" pid = 2877 comm = " mysqld "required_mask =" w "deny_mask =" w "fsuid = 122 ouid = 0
02 de abril 23:52:39 auditoría boggan [2645]: AVC apparmor = "DENIED" operación = "sendmsg" profile = "/ usr / sbin / mysqld" name = "/ run / systemd / notify" pid = 2645 comm = " mysqld "required_mask =" w "deny_mask =" w "fsuid = 122 ouid = 0
02 de abril 23:52:39 kernel boggan: auditoría: tipo = 1400 auditoría (1459655559.419: 33): apparmor = "NEGADO" operación = "sendmsg" perfil = "/ usr / sbin / mysqld" nombre = "/ ejecutar / systemd / notifique "pid = 2645 comm =" mysqld "solicitado_mask =" w "negar_mask =" w "fsuid = 122 ouid = 0
02 de abril 23:52:39 boggan systemd [1]: Error al iniciar el servidor de base de datos MariaDB.
- Asunto: la unidad mariadb.service ha fallado
- Definido por: systemd
- Soporte: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
- 
- La unidad mariadb.service ha fallado.
- 
- El resultado ha fallado.
02 de abril 23:52:39 boggan systemd [1]: mariadb.service: la unidad entró en estado fallido.
02 de abril 23:52:39 boggan systemd [1]: mariadb.service: Error con el resultado 'tiempo de espera'.
15.10 mysql timeout mariadb TJL
fuente
2
La journalctl -xesalida está truncada, ¿puedes actualizar esto? Eche un vistazo más de cerca a los apparmor="DENIED"mensajes (si apparmor está activado en su sistema operativo) ya que esto podría ser un problema durante el inicio de mariadb.
tlo
@tlo lo haré ... solo tendrá que esperar hasta esta noche. No tengo acceso a la máquina desde donde estoy. Después de todo, no pude hacer que funcionara cuando estaba sentado allí, entonces, ¿por qué molestarme en configurarlo para acceso remoto? Definitivamente voy a ver en Aparmor, también. Si se activó, se activó por defecto. No he cambiado nada instalado por el sistema, solo agregué las cosas de LAMP.
TJL
@tlo Actualizó el resultado y agregó un poco de arruga a la descripción. En lugar de golpearlo, me iré por una o dos horas y veré qué pasa ...
TJL
1
@tlo Gracias por la ayuda. Apaparmor fue el culpable.
TJL

Respuestas:

28

Tuve el mismo problema después de actualizar de mysql a mariadb. Lo extraño fue que el inicio del servicio mariadb falló en el tiempo de espera (ya sea en el arranque del sistema o manualmente) mientras que el inicio del servicio mysql tuvo éxito.

La explicación dada por TJL es correcta pero la corrección no funcionó para mí.

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

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

Así que deshabilité el perfil (con aa-disable que parece ser equivalente a la solución de plutocrat )

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

Inhabilité mysqld-akonadi y mysqld-digikam también.

Una recarga de apparmor no fue suficiente, así que tuve que reiniciar y mariadb comenzó perfectamente bien.

ChrisAga
fuente
Confirmando que no podría encontrar una manera de hacerlo funcionar sin reiniciar.
Meetai.com
Esta respuesta funcionó para mí en Kubuntu 18.04.2 LTS. complainy ... apparmor reload( respuesta TJL ) de hecho no fue suficiente.
Marten Koetsier
25

Apaparmor fue el culpable. A pesar del contenido de /etc/apparmor.d/usr.sbin.mysqldser nada más que comentarios y afirmar que estaba allí para que no aparezcan apariciones en MariaDB, eso es exactamente lo que estaba sucediendo.

AppArmor y MySQL en un blog de Oracle proporcionaron lo que necesitaba para descubrir qué estaba pasando.

sudo aa-statuste muestra lo que está haciendo apparmor; lo que en realidad tiene una política impuesta, frente a lo que se acaba de quejar

sudo apt-get install apparmor-utils agrega algunos comandos que facilitan el manejo de los perfiles de apparmor, como ...

sudo aa-complain /usr/sbin/mysqldconvierte el perfil de "imponer" para quejarse. ( aa-enforcelo regresa)

Una vez hecho esto, sudo service apparmor reloadreinicia apparmor y listo ... sudo /etc/init.d/mysql startfunciona, y el servidor permanece activo.

TJL
fuente
1
Mierda, amigo; eso realmente funcionó. Tuve un ligero pánico ya que esto afectó a nuestro servidor de producción y lo dejó inactivo durante un par de horas. No soy un experto como usted y busqué en toda la web varios errores en el archivo /var/log/mysql/error.log. ¡Muchas gracias por esto!
Muqito
1
Lo mismo para mi. Actualicé Ubuntu 14.04 a 16.04 y perdí la capacidad de ejecutar MySQL. ¡Ahora funciona! Muchas gracias por detallar esto: D. ¡He estado buscando por semanas!
Sawtaytoes
No lo hace por mí, pero gracias por el consejo apparmor-utils. Tres años después me estoy poniendo ERROR: /etc/apparmor.d/usr.sbin.mysqld contains no profile.
YetiCGN
14

Tuve que desactivar completamente mysql en apparmor. Una queja no haría nada por mí. Asi que ...

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

Luego reiniciar

plutócrata
fuente
¡Gracias! ¡Esta fue la única solución a mi problema! También actualicé de mysql a mariadb
Thomas Gatt
esto fue lo que funcionó para mí también, muchas gracias
Eman
3

Una solución simple es eliminar cualquier perfil desconocido de AppArmor:

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

¡Funciona!

Loc Luong
fuente
Esto era realmente lo que necesitaba hacer para que todo funcionara, así que gracias. La respuesta aceptada arriba me daría, ERROR: /etc/apparmor.d/usr.sbin.mysqld contains no profileya que eso es exactamente cierto, dado que el archivo solo consta de comentarios. Tal vez en una versión más nueva de AppArmor lo configuraron para fallar con esos archivos, mientras funcionaba en 2016.
YetiCGN
Esta es la respuesta correcta (al menos en 2019). Lo que sucede es que después de la desinstalación de MySql, el perfil de AppArmor para /usr/sbin/mysqldtodavía está cargado en el kernel. Ejecutar aa-remove-unknown(o reiniciar) resuelve esto.
zwets