Zatrzymywanie procesu w systemie Linux: zatrzymanie procesu bez wyłączania niewłaściwej usługi

Proces Linuksa, który blokuje procesor, utrzymuje port otwarty lub nie chce się zamknąć, może szybko doprowadzić do chęci uruchomienia… zabij -9Na początek odradzam to. Prawidłową metodą jest jednoznaczne zidentyfikowanie PID, sprawdzenie, czy proces jest zależny od usługi, a następnie wysłanie czystego sygnału przed jego wymuszeniem.

W tym poradniku pokażemy, jak zatrzymać proces w systemie Linux, nie wyłączając niewłaściwej usługi, nie uszkadzając bazy danych i nie zamykając przypadkowo aktywnej sesji.

Dlaczego nie należy zabijać losowego procesu

Zamówienie zabić Nie wyszukuje programu po nazwie. Wysyła sygnał do jednego lub kilku PIDTo znaczy identyfikatory procesów. Jeśli wybierzesz niewłaściwy PID, Linux i tak wykona żądanie.

Ryzyko występuje przede wszystkim na serwerze: procesem może być webworker, sesja SSH, zadanie tworzenia kopii zapasowej, serwer bazy danych lub usługa uruchomiona przez systemd. Przed podjęciem działań zawsze wolę odpowiedzieć na trzy pytania: który proces powoduje problem, do którego użytkownika należy i która usługa go uruchomiła.

Przed podjęciem działań znajdź PID

Aby uzyskać prosty widok, zacznij od p.s.To polecenie pozwala uniknąć klikania w narzędzie interaktywne i umożliwia czyste skopiowanie PID.

ps -eo pid, ppid, użytkownik, stat, cmd --sort=pid | mniej

Jeśli szukasz konkretnej usługi lub zamówienia, skorzystaj z pgrep z opcją -maWyświetla PID i powiązany wiersz poleceń.

pgrep -a nginx
pgrep -a php-fpm
pgrep -a -u www-data php

Jeśli wolisz bardziej czytelny widok ładunku, możesz również użyć htop pod LinuksemPamiętaj, że narzędzie to pomaga Ci zidentyfikować podejrzanego, a nie decydować za siebie, kogo zabić.

Sprawdź, czy proces zależy od usługi

Przed wysłaniem sygnału sprawdź, czy PID należy do usługi systemd. Często wygodniej jest zatrzymać lub ponownie uruchomić usługę niż zabić izolowany proces.

systemctl status nginx --no-pager
systemctl status php8.4-fpm --no-pager

Jeśli nie znasz dokładnej nazwy usługi, lista usług może Ci pomóc. Szczegółowo opisałem tę sekcję w przewodniku. systemctl i lista usług Linux.

Sprawdź również logi przed wyłączeniem systemu. Często ujawniają one prawdziwą przyczynę: brak pliku, port już używany, limit pamięci, błąd uprawnień lub pętlę aplikacji.

journalctl -u nginx -n 80 --no-pager
journalctl -u nginx -f

Aby monitorować plik dziennika aplikacji na żywo, ogon pod Linuksem pozostaje praktyczne, szczególnie gdy usługa nie zapisuje wszystkiego w dzienniku systemd.

Zrozumienie sygnałów TERM, KILL i użytecznych sygnałów

Imię zabić jest mylące. Polecenie służy głównie do wysyłania sygnału. Domyślnie wysyła SIGTERM, czysty sygnał, który nakazuje procesowi zatrzymanie się.

zabić -l

Trzy sygnały, z którymi będziesz się spotykać najczęściej to:

• TERMIN Lub piętnaście : prośba o czyste zatrzymanie. To sygnał, żeby spróbować najpierw.
• HUP Lub jeden : często używane do poproszenia usługi o ponowne odczytanie konfiguracji, zgodnie z programem.
• ZABIĆ Lub dziewięć : natychmiastowe wymuszone zamknięcie. Proces nie może wyczyścić swoich plików, prawidłowo zamknąć połączeń ani zapisać swojego stanu.

Strony podręcznika zabić I sygnał Udokumentuj te sygnały. W praktyce pamiętaj przede wszystkim o tym: minus dziewięć jest ostatecznością, a nie zamówieniem dla wygody.

Czyste zatrzymanie procesu za pomocą polecenia kill

Po potwierdzeniu prawidłowego PID należy najpierw wysłać TERMINPrzykład z PID tysiąc dwieście trzydzieści cztery :

sudo kill -TERM 1234

Poczekaj kilka sekund i sprawdź, czy proces nadal istnieje:

ps -p 1234 -o pid,stat,cmd

Jeśli zniknął, nie rób nic więcej. Zamiast tego sprawdź logi, aby dowiedzieć się, dlaczego musiałeś go zatrzymać.

journalctl -n 80 --no-pager

Jeśli proces nadal się zawiesza i masz pewność, że nie powinien być kontynuowany, możesz go wymusić:

sudo kill -KILL 1234

To polecenie rezerwuję dla procesów, które naprawdę utknęły. W przypadku bazy danych, przetwarzania plików lub tworzenia kopii zapasowych, wymuszone zamknięcie systemu może pozostawić bałagan. Nie zawsze jest to katastrofalne, ale nie jest nieszkodliwe.

Kiedy używać systemctl zamiast kill

Jeśli proces należy do usługi, użyj systemd. Dzięki temu zachowasz przejrzystszy zapis i umożliwisz menedżerowi usługi zastosowanie prawidłowej sekwencji zamykania.

sudo systemctl stop nginx
sudo systemctl restart nginx
systemctl status nginx --no-pager

Po ponownym uruchomieniu szybko sprawdź status usługi i ostatnie błędy:

systemctl jest aktywny nginx
systemctl --failed
journalctl -u nginx -b --no-pager

W przypadku usług krytycznych utrzymuję również otwartą sesję i testuję nowe połączenie przed zamknięciem starego. Dotyczy to szczególnie protokołu SSH, zapór sieciowych, usług sieciowych i komputerów zdalnych bez konsoli zapasowej.

Używaj pkill bez zbytniego rozszerzania

zabij Pozwala to wysłać sygnał do procesów znalezionych po nazwie lub wzorcu. Jest to wygodne, ale niebezpieczne, jeśli wzorzec jest zbyt niejasny.

Zanim cokolwiek zabijesz, wypisz, co do tego pasuje pgrepStrona podręcznika dot pgrep i pkill Warto pamiętać, że narzędzia te działają na podstawie wzorców.

pgrep -a -f 'konserwacja-skryptu'
pgrep -a -u wdróż 'python'

Jeśli lista jest poprawna, wyślij czysty sygnał:

sudo pkill -TERM -f 'script-maintenance'

Unikaj wzorów, które są zbyt krótkie, np. php, pyton Lub węzeł na serwerze współdzielonym. Ryzykujesz zatrzymanie kilku aplikacji, które nie mają nic wspólnego z Twoim incydentem.

Sprawdź po zatrzymaniu procesu

Po zatrzymaniu procesu nie wychodź od razu. Sprawdź przynajmniej stan systemu, usługę, której dotyczy problem, oraz logi. Często można w ten sposób sprawdzić, czy problem został rozwiązany, czy też powróci za pięć minut.

systemctl --failed
journalctl -p ostrzeżenie..alert -b --no-pager
ps -eo pid,użytkownik,stat,cmd --sort=-%cpu | head

Jeśli problem polegał na zablokowaniu portu, sprawdź także, jaki proces nadal na nim nasłuchuje:

sudo ss -ltnp | grep ':80'
sudo ss -ltnp | grep ':443'

A jeśli potrzebujesz ponownie przeczytać logi z ostatniego uruchomienia, skorzystaj z przewodnika journalctl po ponownym uruchomieniu Linuksa Ta sekcja dobrze ją uzupełnia.

Jeśli proces powróci samoczynnie

Proces, który uruchamia się ponownie natychmiast, niekoniecznie stanowi problem. Może zostać uruchomiony ponownie przez systemd, nadzorcę, zadanie cron, timer lub aplikację główną. W takim przypadku wielokrotne kasowanie PID jest bezcelowe.

systemctl status nazwa-usługi --no-pager
systemctl list-timers --all
crontab -l
sudo crontab -l

Najczystszym podejściem jest zatem usunięcie przyczyny problemu: konfiguracji, brakujących zależności, pętli aplikacji, uprawnień do plików, zajętego portu lub limitu pamięci. zabić Pomaga odzyskać kontrolę. Nie zastępuje diagnozy.

sudo apt update && sudo apt upgrade