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

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'.

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.

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.

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

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!