Perché mariadb continua a morire? Come posso fermarlo?

25

Sto eseguendo MariaDB 10.0.23-0 su Ubuntu 15.10 come server LAMP. Esecuzione sudo /etc/init.d/mysql startrisultati in:

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

L'output di systemctl status mariadb.serviceè:

● mariadb.service - server di database MariaDB
   Caricato: caricato (/lib/systemd/system/mariadb.service; abilitato; preimpostazione fornitore: abilitato)
  Drop-In: /etc/systemd/system/mariadb.service.d
           └─migrated-da-my.cnf-settings.conf
   Attivo: non riuscito (Risultato: timeout) da Sab 2016-03-26 22:52:42 EDT; 26 anni fa
  Processo: 8707 ExecStart = / usr / sbin / mysqld $ MYSQLD_OPTS $ _WSREP_NEW_CLUSTER (codice = uscito, stato = 0 / SUCCESSO)
  Processo: 8706 ExecStartPre = / usr / bin / install -m 755 -o mysql -g root -d / var / run / mysqld (codice = uscito, stato = 0 / SUCCESSO)
 PID principale: 8707 (codice = uscito, stato = 0 / SUCCESSO)

26 mar 22:52:39 boggan systemd [1]: mariadb.service: avvio dell'operazione scaduto. Terminare.
26 mar 22:52:39 boggan mysqld [8707]: 26-03-2016 22:52:39 140105856617216 [Nota] / usr / sbin / mysqld: arresto normale
26 mar 22:52:39 boggan mysqld [8707]: 26-03-2016 22:52:39 140105856617216 [Nota] Utilità di pianificazione eventi: Purging the queue. 0 eventi
26 mar 22:52:39 boggan mysqld [8707]: 26-03-2016 22:52:39 140104920164096 [Nota] InnoDB: FTS ottimizza l'uscita thread.
26 mar 22:52:39 boggan mysqld [8707]: 26-03-2016 22:52:39 140105856617216 [Nota] InnoDB: avvio arresto ...
26 mar 22:52:42 boggan mysqld [8707]: 26-03-2016 22:52:42 140105856617216 [Nota] InnoDB: spegnimento completato; numero sequenza log 3336953
26 mar 22:52:42 boggan mysqld [8707]: 26-03-2016 22:52:42 140105856617216 [Nota] / usr / sbin / mysqld: spegnimento completato
26 mar 22:52:42 boggan systemd [1]: Impossibile avviare il server di database MariaDB.
26 mar 22:52:42 boggan systemd [1]: mariadb.service: l'unità è entrata in stato di errore.
26 mar 22:52:42 boggan systemd [1]: mariadb.service: errore con risultato 'timeout'`

La prima systemdriga è una specie di "bene duh". So che è scaduto. La seconda systemd, dopo le mysqldlinee è un po mistificante, perché fa in start realtà. Un'applicazione (OwnCloud, in particolare) che dipende dal database funziona normalmente ... per i minuti di modifica di MariaDB.

Un'altra domanda suggeriva di usare time /etc/init.d/mysql startper determinare quanto tempo impiegava. L'ho eseguito ripetutamente per confermare l'ora: ogni volta sono pochi secondi su entrambi i lati degli anni '90.

Altre ricerche mi portano a controllare i permessi dei file, che vanno bene ... inoltre, non si avvia, in via temporanea. Ho cercato e spinto al meglio delle mie capacità (certamente limitato quando si tratta di Linux), e non ho fatto alcun passo avanti.

Quindi, la domanda è ... Come posso ottenere il servizio MariaDB per rimanere sveglio?

Come ulteriore ruga, dopo aver scritto questa domanda, ho lasciato la macchina in funzione. Ci sono tornato una settimana dopo (non l'ho toccato tra). Utilizzando lo stesso comando esatto sudo /etc/init.d/mysql start, ha avuto successo. Il demone mysql è stato avviato ed eseguito; è tornato con un [ ok ]rapporto. Ho riavviato per motivi di sperimentazione e sono tornato da dove ho iniziato.

Nel caso in cui sia importante, l'output di journalctl -xeè:

02 apr 23:51:44 boggan systemd [1]: Stopped Leggi i file richiesti in anticipo.
- Oggetto: l'unità ureadahead.service ha terminato l'arresto
- Definito da: systemd
- Supporto: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
- 
- L'unità ureadahead.service ha terminato l'arresto.
02 apr 23:51:55 boggan mysqld [2645]: 2016-04-02 23:51:55 140386161068800 [Note] InnoDB: DDL online: Start
02 apr 23:51:55 boggan mysqld [2645]: 2016-04-02 23:51:55 140386161068800 [Nota] InnoDB: DDL online: inizia a leggere l'indice cluster della tabella e crea file temporanei
02 apr 23:51:55 boggan mysqld [2645]: 2016-04-02 23:51:55 140386161068800 [Nota] InnoDB: DDL online: fine della lettura dell'indice cluster della tabella e creazione di file temporanei
02 apr 23:51:55 boggan mysqld [2645]: 2016-04-02 23:51:55 140386161068800 [Note] InnoDB: DDL online: completato
02 apr 23:51:55 boggan mysqld [2645]: 2016-04-02 23:51:55 140386161068800 [Note] InnoDB: DDL online: completato
02 apr 23:52:06 boggan dbus [713]: [sistema] Impossibile attivare il servizio "org.bluez": timeout
02 apr 23:52:37 boggan systemd [1]: mariadb.service: avvio dell'operazione scaduto. Terminare.
02 apr 23:52:37 boggan mysqld [2645]: 2016-04-02 23:52:37 140386097400576 [Nota] / usr / sbin / mysqld: arresto normale
02 apr 23:52:37 kernel di boggan: audit: tipo = 1400 audit (1459655557.935: 31): apparmor = "DENIED" operazione = "sendmsg" profile = "/ usr / sbin / mysqld" name = "/ run / systemd / notifica "pid = 2645 comm =" mysqld "request_mask =" w "denied_mask =" w "fsuid = 122 ouid = 0
02 apr 23:52:37 audit di boggan [2645]: AVC apparmor = "DENIED" operazione = "sendmsg" profile = "/ usr / sbin / mysqld" name = "/ run / systemd / notification" pid = 2645 comm = " mysqld "request_mask =" w "denied_mask =" w "fsuid = 122 ouid = 0
02 apr 23:52:37 boggan mysqld [2645]: 2016-04-02 23:52:37 140386097400576 [Nota] Utilità di pianificazione eventi: Purging the queue. 0 eventi
02 apr 23:52:37 boggan mysqld [2645]: 2016-04-02 23:52:37 140385225500416 [Nota] InnoDB: FTS ottimizza l'uscita thread.
02 apr 23:52:37 boggan mysqld [2645]: 2016-04-02 23:52:37 140386097400576 [Nota] InnoDB: avvio arresto ...
02 apr 23:52:39 boggan mysqld [2645]: 2016-04-02 23:52:39 140386097400576 [Nota] InnoDB: spegnimento completato; numero sequenza log 3360838
02 apr 23:52:39 boggan mysqld [2645]: 2016-04-02 23:52:39 140386097400576 [Nota] / usr / sbin / mysqld: spegnimento completato
02 apr 23:52:39 kernel di boggan: audit: tipo = 1400 audit (1459655559.419: 32): apparmor = operazione "DENIED" = "sendmsg" profile = "/ usr / sbin / mysqld" name = "/ run / systemd / notifica "pid = 2877 comm =" mysqld "request_mask =" w "denied_mask =" w "fsuid = 122 ouid = 0
02 apr 23:52:39 boggan audit [2877]: AVC apparmor = "DENIED" operazione = "sendmsg" profile = "/ usr / sbin / mysqld" name = "/ run / systemd / notification" pid = 2877 comm = " mysqld "request_mask =" w "denied_mask =" w "fsuid = 122 ouid = 0
02 apr 23:52:39 boggan audit [2645]: AVC apparmor = "DENIED" operazione = "sendmsg" profile = "/ usr / sbin / mysqld" name = "/ run / systemd / notification" pid = 2645 comm = " mysqld "request_mask =" w "denied_mask =" w "fsuid = 122 ouid = 0
02 apr 23:52:39 kernel boggan: audit: tipo = 1400 audit (1459655559.419: 33): apparmor = operazione "DENIED" = "sendmsg" profile = "/ usr / sbin / mysqld" name = "/ run / systemd / notifica "pid = 2645 comm =" mysqld "request_mask =" w "denied_mask =" w "fsuid = 122 ouid = 0
02 apr 23:52:39 boggan systemd [1]: Impossibile avviare il server di database MariaDB.
- Oggetto: unità mariadb.service non riuscita
- Definito da: systemd
- Supporto: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
- 
- L'unità mariadb.service non è riuscita.
- 
- Il risultato non è riuscito.
02 apr 23:52:39 boggan systemd [1]: mariadb.service: unità inserita in stato non riuscito.
02 apr 23:52:39 boggan systemd [1]: mariadb.service: errore con "timeout" del risultato.

— TJL
fonte

2

L' journalctl -xeoutput viene troncato, puoi aggiornarlo? Dai un'occhiata più da vicino ai apparmor="DENIED"messaggi (se apparmor è attivato sul tuo sistema operativo) in quanto ciò potrebbe costituire un problema durante l'avvio di mariadb.

— fino al

@tlo dovrò ... dovrà solo aspettare fino a stasera. Non ho accesso alla macchina da dove mi trovo. Dopotutto, non riuscivo a farlo funzionare quando ero seduto, quindi perché preoccuparsi di configurarlo per l'accesso remoto. Sicuramente guarderò anche in apparmor. Se è stato attivato, è stato attivato per impostazione predefinita. Non ho cambiato nulla installato dal sistema, ho appena aggiunto le cose LAMP.

— TJL

@tlo Aggiornato l'output e ha aggiunto un po 'di rughe alla descrizione. Invece di picchiarci, me ne andrò via per un'ora o due, e vedrò cosa succede ...

— TJL,

1

@tlo Grazie per l'aiuto. l'apparente era il colpevole.

— TJL,

28

Ho avuto lo stesso problema dopo l'aggiornamento da mysql a mariadb. La cosa strana è che l'avvio del servizio mariadb non è riuscito al timeout (all'avvio del sistema o manuale) mentre l'avvio del servizio mysql è riuscito.

La spiegazione fornita da TJL è corretta ma la correzione non ha funzionato per me.

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

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

Quindi ho disabilitato il profilo (con aa-disable che sembra essere equivalente alla soluzione di plutocrate )

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

Ho disabilitato anche mysqld-akonadi e mysqld-digikam.

Una ricarica di apparmor non era abbastanza, quindi ho dovuto riavviare e mariadb è iniziato perfettamente.

— ChrisAga
fonte

Confermando che non è stato possibile trovare un modo per farlo funzionare senza riavviare.

— Meetai.com

Questa risposta ha funzionato per me su Kubuntu 18.04.2 LTS. complaine ... apparmor reload( rispondere a TJL ) in effetti non era abbastanza.

— Marten Koetsier,

25

l'apparente era il colpevole. Nonostante il contenuto di /etc/apparmor.d/usr.sbin.mysqldessere nient'altro che commenti e affermando che era lì in modo che l'apparmor non si strozzasse con MariaDB, è esattamente quello che stava succedendo.

AppArmor e MySQL su un blog Oracle hanno fornito ciò di cui avevo bisogno per capire cosa stava succedendo.

sudo aa-statusti mostra cosa sta facendo apparmor; ciò che in realtà ha una politica applicata, rispetto a ciò che è appena pronto a lamentarsi.

sudo apt-get install apparmor-utils aggiunge alcuni comandi che semplificano la gestione dei profili di apparmor, come ...

sudo aa-complain /usr/sbin/mysqldtrasforma il profilo da "imponi" per lamentarsi. (lo aa-enforcegira indietro.)

Fatto ciò, sudo service apparmor reloadriavvia apparmor e voilà ... sudo /etc/init.d/mysql startfunziona e il server rimane attivo.

— TJL
fonte

1

Santo merda amico; che ha funzionato davvero. Ho avuto un leggero panico poiché questo ha influenzato il nostro server di produzione lasciandolo inattivo per un paio d'ore. Non sono un esperto proprio come te e ho cercato in tutto il web vari errori nel file /var/log/mysql/error.log. Grazie mille per questo!

— Muqito,

1

Stessa cosa per me. Ho eseguito l'aggiornamento da Ubuntu 14.04 a 16.04 e ho perso la capacità di eseguire MySQL. Ora funziona! Grazie mille per il dettaglio: D. Sto cercando settimane!

— Sawtaytoes,

Non è abbastanza per me, ma grazie per la segnalazione apparmor-utils. Tre anni dopo sto arrivando ERROR: /etc/apparmor.d/usr.sbin.mysqld contains no profile.

— YetiCGN il

14

Ho dovuto disabilitare completamente mysql in apparmor. Un reclamo aa non farebbe nulla per me. Così ...

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

Quindi riavviare

— plutocrate
fonte

Grazie! Questa era l'unica soluzione al mio problema! Ho anche aggiornato da mysql a mariadb

— Thomas Gatt il

questo è ciò che ha funzionato anche per me, grazie mille

— Eman,

3

Una soluzione semplice è rimuovere qualsiasi profilo AppArmor sconosciuto:

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

Funziona!

— Loc Luong
fonte

Questo era in realtà quello che dovevo fare per far funzionare le cose, quindi grazie. La risposta accettata sopra mi darebbe ERROR: /etc/apparmor.d/usr.sbin.mysqld contains no profilecome è esattamente vero, dato che il file è composto solo da commenti. Forse in una versione più recente di AppArmor l'hanno impostato per fallire con quei file, mentre ha funzionato nel 2016.

— YetiCGN

Questa è la risposta corretta (almeno nel 2019). Quello che succede è che dopo la disinstallazione di MySql, il profilo AppArmor per /usr/sbin/mysqldè ancora caricato nel kernel. L'esecuzione aa-remove-unknown(o il riavvio) risolve questo problema.

— zwets