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.
journalctl -xewyjściowe są obcięte, czy możesz to zaktualizować? Przyjrzyj się bliżejapparmor="DENIED"komunikatom (jeśli w systemie operacyjnym jest włączony apparmor), ponieważ może to stanowić problem podczas uruchamiania mariadb.Odpowiedzi:
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.
Więc wyłączyłem profil (z aa-disable, który wydaje się być równoważny rozwiązaniu plutocrat )
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.
źródło
complaini... apparmor reload( odpowiedź TJL ) rzeczywiście nie wystarczyło.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-utilsdodaje 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.źródło
apparmor-utils. Trzy lata później dostajęERROR: /etc/apparmor.d/usr.sbin.mysqld contains no profile.Musiałem całkowicie wyłączyć mysql w apparmor. Narzekanie nic by mi nie zrobiło. Więc ...
Następnie uruchom ponownie
źródło
Prostym rozwiązaniem jest usunięcie wszelkich nieznanych profili AppArmor:
To działa!
źródło
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./usr/sbin/mysqldjest nadal ładowany do jądra. Uruchomienieaa-remove-unknown(lub ponowne uruchomienie) rozwiązuje ten problem.