Czym dokładnie jest „zlecenie zatrzymania”, jak w „Zadaniu zatrzymania działa…”?

Po wydaniu polecenia zamknięcia czasami pojawia się następujący komunikat o stanie:

A stop job is running for Session 1 of user xy

a następnie system zawiesza się na jakiś czas lub na zawsze w zależności od ???

Czym dokładnie jest „praca stop”?

Ponadto, dlaczego czasami szacuje czas, który zajmuje dość dokładnie, a innym razem może trwać wiecznie?

systemd działa wewnętrznie pod względem kolejki „zadań”. Każde zadanie (nieco upraszczając) to czynność do wykonania: zatrzymanie, sprawdzenie, uruchomienie lub ponowne uruchomienie określonej jednostki .

Kiedy (na przykład) instruujesz systemd, aby uruchomił jednostkę serwisową , opracowuje listę zadań zatrzymania i uruchomienia dla dowolnych jednostek (jednostek serwisowych, jednostek montażowych, jednostek urządzeń itd.), Które są niezbędne do osiągnięcia tego celu, zgodnie z wymagania i zależności jednostek, porządkuje je zgodnie z relacjami zamawiania jednostek, opracowuje i (jeśli to możliwe) naprawia wszelkie sprzeczności i (jeśli ten ostatni krok się powiedzie) umieszcza je w kolejce.

Następnie próbuje wykonać kolejkowane „zadania”.

Zadanie zatrzymania jest uruchomione dla sesji 1 użytkownika xy

Jednostka nazwę wyświetlaną tutaj jest Session 1 of user xy. Będzie to (z nazwy wyświetlanej) jednostka sesyjna , a nie jednostka serwisowa . Jest to abstrakcja sesji logowania w przestrzeni użytkownika, która jest utrzymywana przez logindprogram systemd i jego wtyczki PAM. Jest to (zasadniczo i teoretycznie) zgrupowanie wszystkich procesów, które ten użytkownik uruchamia gdzieś jako „sesję logowania”.

Zadanie, które zostało zakwalifikowane przeciwko niemu, to stop. I to prawdopodobnie trwa długo, ponieważ Systemd ludzie błędnie utożsamił sesji rozłączenia z sesji zamykania . Łamią to pierwsze, aby drugie działało, aw odpowiedzi niektórzy ludzie zmieniają system, aby złamać ten drugi, aby pierwszy działał. Systematyczni ludzie naprawdę powinni rozpoznać, że są to dwie różne rzeczy.

Podczas sesji logowania masz coś, co ignoruje SIGTERMlub którego zakończenie zajmuje dużo czasu, gdy to zobaczysz SIGTERM. Jak na ironię, ta pierwsza to długotrwałe zachowanie niektórych powłok kontrolujących pracę. Prawidłowym sposobem zakończenia liderów sesji logowania, gdy są one tymi konkretnymi powłokami kontroli zadań, jest poinformowanie ich, że sesja została zawieszona , po czym kończą wszystkie swoje zadania (zadanie innego rodzaju niż wewnętrzne zadanie systemowe), a następnie zakończyć się.

Faktycznie dzieje się tak, że systemd czeka na przekroczenie limitu czasu zatrzymania urządzenia, aż zacznie się uciekać SIGKILL. Ten limit czasu można oczywiście skonfigurować dla każdej jednostki i można go ustawić tak, aby nigdy nie przekraczał limitu czasu. Dlatego potencjalnie można zobaczyć różne zachowania.

Dalsza lektura

• Lennart Poettering (2015). systemd . systemowe strony podręcznika. Freedesktop.org.
• Jonathan de Boyne Pollard (01.06.2016). systemd zabija procesy w tle po wylogowaniu użytkownika . 825394. Śledzenie błędów Debiana.
• Lennart Poettering (2015). systemd.kill . systemowe strony podręcznika. Freedesktop.org.
• Lennart Poettering (2015). systemd.service . systemowe strony podręcznika. Freedesktop.org.
• Dlaczego bash ignoruje SIGTERM?
• /superuser/1102242/

Te wiadomości pochodzą z systemd, który jest systemem inicjującym, który uruchamia i zatrzymuje zadania. Zadania mogą być demonami, ale mogą również wykonywać małe zadania, takie jak montowanie i odmontowywanie dysków, usuwanie / tmp lub zapisywanie i przywracanie jasności ekranu podczas rozruchu. systemctl list-unitsdaje ci pomysł. Systemd używa słowa „jednostka” i „zadanie”, co oznacza prawie to samo.

Kiedy zadanie jest zatrzymywane, tak jak w przypadku systemctl stop ..., wtedy pytanie brzmi, jak długo trzeba czekać na zakończenie zadania, zanim zadeklaruje się błąd i zabije proces zadania SIGKILLsygnałem. Naprawdę nie chcemy używać, SIGKILLchyba że musimy, ponieważ nie daje to możliwości czystego zakończenia procesu. W przypadku niektórych procesów kilka sekund może być wystarczającym czasem na zgłoszenie awarii, w przypadku innych procesów, takich jak baza danych, może istnieć znaczna liczba operacji we / wy sieci i dysku, aby zadanie zakończyło się czysto, a zatem możemy dać tym jednostkom kilka minut na dokładne zamknięcie .

To, co widzisz po wyłączeniu, jest odpowiednikiem, systemctl stop $UNIT_NAMEktórego uruchomienie zajmuje trochę czasu. Istnieje licznik, który pokazuje upływające sekundy i maksymalny czas oczekiwania przed wydaniem SIGKILL, a zamknięcie nastąpi niezależnie.

O ile nie ma dobrych powodów, aby spodziewać się dużego opóźnienia, zwykle oznacza to jakąś awarię. Może to zależeć od tego, czy serwer DHCP nie odpowiada na wydanie, a więc działanie wydania wymaga przekroczenia limitu czasu lub błędu powodującego, że demon nigdy nie wychodzi.

Niektóre usługi są zablokowane i systemd czeka na zakończenie. Systemd prawdopodobnie nie określa dokładnie czasu, jaki zajmie, czas (zwykle 90 sekund) to czas, przez który systemd będzie czekać, zanim skończy się cierpliwość. Zobacz ten post:

Zadanie zatrzymania jest uruchomione dla sesji c2 użytkownika

„Zadania zatrzymania” mają miejsce, gdy systemdczeka się na zatrzymanie określonego „zadania”, np. Proces, który musi zostać zakończony przed kontynuowaniem. Jeśli zobaczysz komunikat ostrzegawczy, że „uruchomione jest zadanie zatrzymania ...” (itp.), Technicznie oznacza to, że coś czeka w kolejce zadań.

Zanim jednak przejrzysz całą kolejkę zadań systemowych, pamiętaj, że czasami te komunikaty ostrzegawcze są wynikiem pośrednim czynników środowiskowych (w rzeczywistości komunikat ten jest nawet określany w repozytorium GitHub jako możliwy błąd).

Na przykład: otrzymywaliśmy komunikaty związane z „zatrzymaniem pracy” i nie mogliśmy dowiedzieć się, dlaczego .... okazało się, że na dysku prawie brakowało miejsca i zaczęło się dziwnie zachowywać.

Naprawiłem serwer na większy dysk i zrestartowałem go;)