Usługi Linux: Polecenia Systemctl, które należy znać przed losowym ponownym uruchomieniem

Przed ponownym uruchomieniem usługi Linuksa zawsze wolę sprawdzić, co faktycznie działa. Na komputerze z systemowy, systemctl Aplikacja zapewnia już niemal wszystko, czego potrzebujesz: aktywne usługi, niedziałające usługi, automatyczne uruchamianie, szczegółowy status i najnowsze przydatne wiadomości.

Dotyczy to zwłaszcza serwera. Uruchom ponownie nginx, ssh, mariadb Usługa biznesowa, nie sprawdzając swojego statusu, może zakończyć sesję, przerwać działanie witryny lub zamaskować błąd konfiguracji. Oto polecenia, które musisz znać, aby poprawnie wyświetlić listę usług Linuxa, odfiltrować to, co istotne, a następnie zdecydować, czy ponowne uruchomienie jest rzeczywiście konieczne.

Wyświetl listę aktywnych usług za pomocą systemctl

Najbardziej bezpośrednim poleceniem jest wyświetlenie aktualnie załadowanych jednostek typu usługowego:

systemctl list-units --type=service

Otrzymasz listę z kilkoma kolumnami. Najważniejsze z nich to: OBCIĄŻENIE, AKTYWNY, ZASTĄPIĆ I OPISW praktyce patrzę głównie na AKTYWNY I ZASTĄPIĆ :usługa może zostać załadowana, ale zatrzymana, błędnie lub po prostu zakończona, ponieważ jest to jej normalne zachowanie.

Aby zobaczyć tylko aktualnie uruchomione usługi:

systemctl list-units --type=service --state=running

Aby wyświetlić zawieszone usługi:

systemctl list-units --type=service --state=exited

Nie panikuj, jeśli widzisz usługi w wyszedłNiektóre procesy inicjują krótką akcję, a następnie zatrzymują się normalnie. Przed stwierdzeniem problemu konieczne jest zbadanie danej usługi.

Wyświetl usługi, które zakończyły się niepowodzeniem

Gdy maszyna ulegnie awarii, zacznij od tego polecenia:

systemctl --failed

Wyświetla jednostki, które systemd uznaje za uszkodzone. Jest to bardziej przydatne niż restart bez wiedzy użytkownika, ponieważ od razu widzisz dokładną nazwę usługi do sprawdzenia.

Przykład :

status systemctl ssh

lub według rozkładu:

stan systemctl sshd

Dane wyjściowe pokazują status usługi, używany plik jednostki, główny identyfikator PID, jeśli usługa jest uruchomiona, oraz kilka ostatnich wierszy dziennika. Jeśli potrzebujesz zdiagnozować nieudany rozruch, te kilka wierszy często stanowi pierwszą wskazówkę.

Określanie, czy usługa uruchamia się automatycznie

Usługa może być aktywna teraz, bez aktywacji podczas uruchamiania. Możliwa jest również sytuacja odwrotna: usługa może być aktywowana, ale zatrzymana z powodu awarii lub dlatego, że nie została jeszcze uruchomiona.

Aby wyświetlić listę plików jednostki i ich stan podczas uruchamiania:

systemctl list-unit-files --type=service

Najczęstsze stany to:

włączony :usługa jest zaprojektowana tak, aby uruchamiać się automatycznie;
wyłączony : nie uruchamia się automatycznie;
statyczny :nie jest aktywowany bezpośrednio, ale może być przywołany przez inną jednostkę;
zamaskowany :usługa jest blokowana celowo.

Aby sprawdzić konkretną usługę:

systemctl jest włączony nginx
systemctl jest aktywny nginx

Pierwsze polecenie odpowiada na pytanie o automatyczne uruchomienie. Drugie odpowiada na pytanie o aktualny stan. Żadna z tych informacji nie zastępuje… status systemctl, ale są przydatne w skrypcie sterującym lub szybkiej liście kontrolnej.

Filtruj listę bez gubienia się w niej

Na nieco obciążonym serwerze cała lista szybko staje się długa. Możesz filtrować za pomocą grep jeśli szukasz rodziny usług:

systemctl list-units --type=service | grep ssh

Aby wyświetlić tylko aktywne usługi bez pagera:

systemctl list-units --type=service --state=running --no-pager

A jeśli chcesz uzyskać bardziej czytelny wynik w zgłoszeniu lub krótkiej diagnostyce:

systemctl list-units --type=service --state=failed --no-pager

Na serwerze zdalnym często dodaję --no-pagerDzięki temu unikniesz utknięcia w interaktywnym wyświetlaczu, szczególnie gdy szybko pracujesz za pośrednictwem protokołu SSH.

Przed ponownym uruchomieniem przeczytaj dzienniki

Jeśli usługa doświadcza błędu, nie rozpoczynaj jej od razu uruchom ponownieNajpierw spójrz na gazety:

journalctl -u nginx -n 50 --no-pager

Aby śledzić relacje na żywo:

journalctl -u nginx -f

Często pojawia się błąd, taki jak port już używany, nieprawidłowy plik konfiguracyjny, nieprawidłowe uprawnienie lub brak zależności. Jeśli dopiero zaczynasz przygodę z dziennikami systemd, podałem również szczegółowe informacje. Jak odczytać logi ostatniego uruchomienia Linuksa za pomocą journalctl.

Uruchom ponownie dopiero po zakończeniu sprawdzeń.

Po zidentyfikowaniu usługi sprawdź jej konfigurację, gdy narzędzie na to pozwala. Na przykład w przypadku Nginx:

nginx -t

W przypadku SSH zachowaj jeszcze większą ostrożność. Jeśli zrestartujesz niewłaściwą usługę lub konfiguracja będzie nieprawidłowa, możesz utracić dostęp zdalny. Pozostaw otwartą sesję, sprawdź zaporę sieciową, a następnie skorzystaj z SSH. przeładować kiedy to wystarczy.

sudo systemctl przeładuj ssh
sudo systemctl restart ssh

Zamówienie przeładować żąda od usługi ponownego odczytania konfiguracji bez całkowitego jej zatrzymywania, jeśli usługa to obsługuje. uruchom ponownie Usługa zostaje przerwana, a następnie uruchomiona ponownie. To nie jest ten sam poziom ryzyka.

Jeśli zmodyfikowałeś plik jednostki systemd, weź pod uwagę różnicę między demon-przeładowaniePrzypadek ten wyjaśniłem osobno w artykule. Systemctl daemon-reload: kiedy naprawdę należy go używać w systemie Linux?.

Mini lista kontrolna przed skorzystaniem z usługi

Wymień odpowiednie usługi systemctl list-units --type=service.
Sprawdź błędy za pomocą systemctl --failed.
Przeczytaj dokładny status za pomocą systemctl status nazwa-usługi.
Spójrz na dzienniki z journalctl -u nazwa-usługi.
Przetestuj konfigurację, jeśli usługa oferuje polecenie walidacji.
Woleć przeładować ma uruchom ponownie gdy jest tolerowane i wystarczające.

Dokumentacja systemctl Szczegółowo opisuje wszystkie opcje, ale w codziennym użytkowaniu polecenia te obejmują już większość diagnostyki. Moja rada: jeśli nie wiesz, dlaczego restartujesz usługę, nie rób tego jeszcze. Wypisz problemy, przeczytaj logi i podejmij działania.