Dlaczego mariadb wciąż umiera? Jak mogę to zatrzymać?

25

Używam MariaDB 10.0.23-0 na Ubuntu 15.10 jako serwer LAMP. Uruchamianie sudo /etc/init.d/mysql startwyników w:

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

Dane wyjściowe systemctl status mariadb.serviceto:

● mariadb.service - serwer bazy danych MariaDB
   Załadowano: załadowano (/lib/systemd/system/mariadb.service; włączone; preset dostawcy: włączony)
  Drop-In: /etc/systemd/system/mariadb.service.d
           Igrmigrated-from-my.cnf-settings.conf
   Aktywny: nieudany (Wynik: upłynął limit czasu) od sob. 26.03.2016 22:52:42 EDT; 26s temu
  Proces: 8707 ExecStart = / usr / sbin / mysqld $ MYSQLD_OPTS $ _WSREP_NEW_CLUSTER (kod = zakończony, status = 0 / SUKCES)
  Proces: 8706 ExecStartPre = / usr / bin / install -m 755 -o mysql -g root -d / var / run / mysqld (kod = zakończony, status = 0 / SUKCES)
 Główny PID: 8707 (kod = zakończony, status = 0 / SUKCES)

26 marca 22:52:39 boggan systemd [1]: mariadb.service: Upłynął limit czasu rozpoczęcia operacji. Zakończenie
26 marca 22:52:39 boggan mysqld [8707]: 26.03.2016 22:52:39 140105856617216 [Uwaga] / usr / sbin / mysqld: Normalne wyłączenie
26 marca 22:52:39 boggan mysqld [8707]: 26.03.2016 22:52:39 140105856617216 [Uwaga] Harmonogram wydarzeń: Czyszczenie kolejki. 0 wydarzeń
26 marca 22:52:39 boggan mysqld [8707]: 26.03.2016 22:52:39 140104920164096 [Uwaga] InnoDB: FTS optymalizuje wyjście z wątku.
26 marca 22:52:39 boggan mysqld [8707]: 26.03.2016 22:52:39 140105856617216 [Uwaga] InnoDB: Rozpoczęcie zamykania ...
26 marca 22:52:42 boggan mysqld [8707]: 26.03.2016 22:52:42 140105856617216 [Uwaga] InnoDB: Zakończono zamykanie; numer kolejny log 3336953
26 marca 22:52:42 boggan mysqld [8707]: 26.03.2016 22:52:42 140105856617216 [Uwaga] / usr / sbin / mysqld: Zakończono zamykanie
26 marca 22:52:42 boggan systemd [1]: Nie udało się uruchomić serwera bazy danych MariaDB.
26 marca 22:52:42 boggan systemd [1]: mariadb.service: Jednostka weszła w stan awarii.
26 marca 22:52:42 boggan systemd [1]: mariadb.service: Błąd z powodu przekroczenia limitu czasu

Pierwsza systemdlinia to coś w rodzaju „well duh”. Wiem, że upłynął limit czasu. Drugi systemd, po mysqldlinii jest nieco tajemnicze, bo to robi w rzeczywistości początku. Aplikacja (w szczególności OwnCloud), która zależy od bazy danych, działa normalnie ... na minutę i zmiany, że MariaDB jest uruchomiona.

Inne pytanie sugerowało użycie, time /etc/init.d/mysql startaby określić, ile to trwało. Uruchomiłem go wielokrotnie, aby potwierdzić czas - za każdym razem jest to kilka sekund po obu stronach lat 90.

Inne badania doprowadziły mnie do sprawdzenia uprawnienia do plików, które są w porządku ... Poza tym, to nie uruchomi się, tymczasowo. Szturchałem i naciskałem na najlepsze z moich (co prawda ograniczone, jeśli chodzi o Linuksa) umiejętności i nie zrobiłem żadnych postępów.

Pytanie brzmi więc ... Jak sprawić, by usługa MariaDB pozostała aktywna?

Jako dodatkowy zmarszczek po napisaniu tego pytania pozostawiłem maszynę gotową do pracy. Wróciłem do niego tydzień później (nie dotknąłem go między). Przy użyciu dokładnie tego samego polecenia, sudo /etc/init.d/mysql startpowiodło się. Demon mysql uruchomił się i uruchomił; wrócił z [ ok ]raportem. Zrestartowałem się ze względu na eksperyment i wróciłem do punktu wyjścia.

W przypadku, gdy ma to znaczenie, wynikiem journalctl -xejest:

02 kwietnia 23:51:44 boggan systemd [1]: Zatrzymano Przeczytaj wymagane pliki z góry.
- Temat: Jednostka ureadahead.service zakończyła zamykanie
- Zdefiniowane przez: systemd
- Wsparcie: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
- 
- Jednostka ureadahead.service zakończyła zamykanie.
02 kwietnia 23:51:55 boggan mysqld [2645]: 02.04.2016 23:51:55 140386161068800 [Uwaga] InnoDB: Online DDL: Start
02 kwietnia 23:51:55 boggan mysqld [2645]: 2016-04-02 23:51:55 140386161068800 [Uwaga] InnoDB: Online DDL: Rozpocznij czytanie klastrowanego indeksu tabeli i utwórz pliki tymczasowe
02 kwietnia 23:51:55 boggan mysqld [2645]: 2016-04-02 23:51:55 140386161068800 [Uwaga] InnoDB: Online DDL: Koniec odczytu klastrowanego indeksu tabeli i tworzenie plików tymczasowych
02 kwietnia 23:51:55 boggan mysqld [2645]: 02.04.2016 23:51:55 140386161068800 [Uwaga] InnoDB: Online DDL: zakończone
02 kwietnia 23:51:55 boggan mysqld [2645]: 02.04.2016 23:51:55 140386161068800 [Uwaga] InnoDB: Online DDL: zakończone
02 kwietnia 23:52:06 boggan dbus [713]: [system] Nie można aktywować usługi „org.bluez”: upłynął limit czasu
02 kwietnia 23:52:37 boggan systemd [1]: mariadb.service: Upłynął limit czasu rozpoczęcia operacji. Zakończenie
02 kwietnia 23:52:37 boggan mysqld [2645]: 02.04.2016 23:52:37 140386097400576 [Uwaga] / usr / sbin / mysqld: Normalne zamknięcie
02 kwietnia 23:52:37 bogane jądro: audit: type = 1400 audit (1459655557.935: 31): apparmor = operacja „DENIED” = „sendmsg” profile = "/ usr / sbin / mysqld" name = "/ run / systemd / powiadom "pid = 2645 comm =" mysqld "Request_mask =" w "denied_mask =" w "fsuid = 122 ouid = 0
02 kwietnia 23:52:37 boggan audit [2645]: AVC apparmor = Operacja "DENIED" = "sendmsg" profile = "/ usr / sbin / mysqld" name = "/ run / systemd / powiadomienie" pid = 2645 comm = " mysqld "Request_mask =" w "denied_mask =" w "fsuid = 122 ouid = 0
02 kwietnia 23:52:37 boggan mysqld [2645]: 02.04.2016 23:52:37 140386097400576 [Uwaga] Harmonogram wydarzeń: Czyszczenie kolejki. 0 wydarzeń
02 kwietnia 23:52:37 boggan mysqld [2645]: 2016-04-02 23:52:37 140385225500416 [Uwaga] InnoDB: FTS optymalizuje wyjście z wątku.
02 kwietnia 23:52:37 boggan mysqld [2645]: 02.04.2016 23:52:37 140386097400576 [Uwaga] InnoDB: Rozpoczęcie zamykania ...
02 kwietnia 23:52:39 boggan mysqld [2645]: 02.04.2016 23:52:39 140386097400576 [Uwaga] InnoDB: Zakończono zamykanie; numer kolejny log 3360838
02 kwietnia 23:52:39 boggan mysqld [2645]: 02.04.2016 23:52:39 140386097400576 [Uwaga] / usr / sbin / mysqld: Zakończono zamykanie
02 kwietnia 23:52:39 boggan kernel: audit: type = 1400 audit (1459655559.419: 32): apparmor = operacja „DENIED” = „sendmsg” profile = "/ usr / sbin / mysqld" name = "/ run / systemd / powiadom "pid = 2877 comm =" mysqld "Request_mask =" w "denied_mask =" w "fsuid = 122 ouid = 0
02 kwietnia 23:52:39 boggan audit [2877]: AVC apparmor = Operacja "DENIED" = "sendmsg" profile = "/ usr / sbin / mysqld" name = "/ run / systemd / powiadomienie" pid = 2877 comm = " mysqld "Request_mask =" w "denied_mask =" w "fsuid = 122 ouid = 0
02 kwietnia 23:52:39 boggan audit [2645]: AVC apparmor = Operacja "DENIED" = "sendmsg" profile = "/ usr / sbin / mysqld" name = "/ run / systemd / powiadomienie" pid = 2645 comm = " mysqld "Request_mask =" w "denied_mask =" w "fsuid = 122 ouid = 0
02 kwietnia 23:52:39 boggan jądro: audit: type = 1400 audit (1459655559.419: 33): apparmor = operacja „DENIED” = „sendmsg” profile = "/ usr / sbin / mysqld" name = "/ run / systemd / powiadom "pid = 2645 comm =" mysqld "Request_mask =" w "denied_mask =" w "fsuid = 122 ouid = 0
02 kwietnia 23:52:39 boggan systemd [1]: Nie udało się uruchomić serwera bazy danych MariaDB.
- Temat: Awaria jednostki mariadb.service
- Zdefiniowane przez: systemd
- Wsparcie: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
- 
- Awaria urządzenia mariadb.service.
- 
- Wynik nie powiódł się.
02 kwietnia 23:52:39 boggan systemd [1]: mariadb.service: Jednostka weszła w stan awarii.
02 kwietnia 23:52:39 boggan systemd [1]: mariadb.service: Błąd wyniku „timeout” wyniku.

— TJL
źródło

2

Dane journalctl -xewyjściowe są obcięte, czy możesz to zaktualizować? Przyjrzyj się bliżej apparmor="DENIED"komunikatom (jeśli w systemie operacyjnym jest włączony apparmor), ponieważ może to stanowić problem podczas uruchamiania mariadb.

— tlo

@ tlo Będę ... będę musiał poczekać do wieczora. Nie mam dostępu do maszyny, z której jestem. W końcu nie mogłem go uruchomić, kiedy na nim siedziałem, więc po co zawracać sobie głowę konfigurowaniem go do zdalnego dostępu. Na pewno też przyjrzę się zbroi. Jeśli był aktywowany, był aktywowany domyślnie. Nie zmieniłem niczego zainstalowanego przez system, po prostu dodałem rzeczy LAMP.

— TJL

@tlo Zaktualizowałem wyjście i dodałem trochę zmarszczek do opisu. Zamiast na niego walić, odejdę na godzinę lub dwie i zobaczę, co się stanie ...

— TJL

1

@ tlo Dziękuję za pomoc. winowajcą był strach.

— TJL,

28

Miałem ten sam problem po aktualizacji z mysql do mariadb. Dziwną rzeczą było to, że uruchomienie mariadbu usługi nie powiodło się po przekroczeniu limitu czasu (podczas rozruchu systemu lub ręcznie), podczas gdy uruchomienie mysql usługi powiodło się.

Wyjaśnienie podane przez TJL jest słuszne, ale korekta nie działała dla mnie.

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

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

Więc wyłączyłem profil (z aa-disable, który wydaje się być równoważny rozwiązaniu plutocrat )

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

Wyłączyłem również mysqld-akonadi i mysqld-digikam.

Przeładowanie zbroi nie wystarczyło, więc musiałem się zrestartować i mariadb zaczął się doskonale.

— ChrisAga
źródło

Potwierdzenie, że nie można znaleźć sposobu, aby działało bez ponownego uruchamiania.

— Meetai.com

Ta odpowiedź działała dla mnie na Kubuntu 18.04.2 LTS. complaini ... apparmor reload( odpowiedź TJL ) rzeczywiście nie wystarczyło.

— Marten Koetsier

25

winowajcą był strach. Pomimo treści /etc/apparmor.d/usr.sbin.mysqldbycia jedynie komentarzami i twierdzeniem, że tak było, aby zbroja nie dusiła się w MariaDB, dokładnie tak się działo.

AppArmor i MySQL na blogu Oracle zapewniły to, czego potrzebowałem, aby dowiedzieć się, co się dzieje.

sudo aa-statuspokazuje, co robi zbroja; co faktycznie ma egzekwowane zasady, w porównaniu do tego, co właśnie narzeka.

sudo apt-get install apparmor-utils dodaje kilka poleceń, które ułatwiają zarządzanie profilami Apparmor, takich jak ...

sudo aa-complain /usr/sbin/mysqldzmienia profil z „egzekwuj” na narzekanie. ( aa-enforceodwraca to.)

Gdy to zrobisz, sudo service apparmor reloaduruchomi ponownie apparmor, i voila ... sudo /etc/init.d/mysql startdziała, a serwer pozostaje.

— TJL
źródło

1

Kurwa, stary; to faktycznie działało. Miałem niewielką panikę, ponieważ wpłynęło to na nasz serwer produkcyjny, pozostawiając go na kilka godzin. Nie jestem ekspertem tak jak ty i szukałem w Internecie różnych błędów w pliku /var/log/mysql/error.log. Dziękuję ci za to!

— Muqito

1

Dla mnie to samo. Zaktualizowałem system z Ubuntu 14.04 do 16.04 i straciłem możliwość uruchamiania MySQL. Teraz działa! Dziękuję bardzo za opisanie tego: D. Szukałem od tygodni!

— Sawtaytoes

Nie do końca to dla mnie robi, ale dzięki za napiwek apparmor-utils. Trzy lata później dostaję ERROR: /etc/apparmor.d/usr.sbin.mysqld contains no profile.

— YetiCGN

14

Musiałem całkowicie wyłączyć mysql w apparmor. Narzekanie nic by mi nie zrobiło. Więc ...

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

Następnie uruchom ponownie

— plutokrata
źródło

Dziękuję Ci! To było jedyne rozwiązanie mojego problemu! Uaktualniłem również z mysql do mariadb

— Thomas Gatt

to też zadziałało dla mnie, dziękuję bardzo

— Eman

3

Prostym rozwiązaniem jest usunięcie wszelkich nieznanych profili AppArmor:

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

To działa!

— Loc Luong
źródło

Właśnie to musiałem zrobić, aby wszystko działało, więc dziękuję. Przyjęta powyżej odpowiedź dałaby mi to, ERROR: /etc/apparmor.d/usr.sbin.mysqld contains no profileponieważ jest to dokładnie prawda, ponieważ plik zawiera tylko komentarze. Może w nowszej wersji AppArmor spowodowali, że zawiodła z tymi plikami, podczas gdy działała w 2016 r.

— YetiCGN

To poprawna odpowiedź (przynajmniej w 2019 r.). Co się dzieje, że po deinstalacji MySql profil AppArmor /usr/sbin/mysqldjest nadal ładowany do jądra. Uruchomienie aa-remove-unknown(lub ponowne uruchomienie) rozwiązuje ten problem.

— zwets