Które z poleceń systemu Linux powoduje zakończenie procesu?
A. end
B. null
C. kill
D. dead
Pytanie z egzaminu CKE, październik 2013 (arkusz E.12-X-13.10).
Polecenie kill jest standardowym narzędziem w systemach Linux/Unix służącym do wysyłania sygnałów do procesów. Najczęściej kojarzy się je z zakończeniem procesu, bo domyślnie wysyła sygnał SIGTERM, czyli prośbę do programu o poprawne zakończenie pracy. To ważne: kill nie zawsze od razu „zabija” proces brutalnie, tylko najpierw daje mu szansę na zamknięcie plików, zapisanie danych i posprzątanie zasobów. Praktyczny przykład to kill 1234, gdzie 1234 jest identyfikatorem PID procesu, znalezionym np. przez ps aux, top albo pgrep. Gdy proces nie reaguje, administrator może użyć kill -9 1234, czyli sygnału SIGKILL, ale moim zdaniem to powinna być ostateczność, bo program nie ma wtedy czasu na bezpieczne zakończenie. Dobra praktyka administracyjna mówi, żeby najpierw sprawdzić, co kończymy, czyj to proces i czy nie jest to usługa systemowa. Przy usługach często lepiej użyć systemctl stop nazwa_usługi, bo systemd wykona zatrzymanie w bardziej kontrolowany sposób. W pracy z Linuxem znajomość kill, PID, sygnałów SIGTERM, SIGKILL i narzędzi diagnostycznych to absolutna podstawa administracji procesami.
W Linuksie zakończenie procesu nie odbywa się poleceniami typu end, null ani dead, mimo że ich nazwy mogą brzmieć intuicyjnie po angielsku. To dość częsty błąd myślowy: ktoś tłumaczy sobie „koniec” jako end albo „martwy” jako dead i zakłada, że system ma takie proste polecenie. Powłoka Linuxa działa jednak na konkretnych programach i wbudowanych komendach, a nie na opisowych słowach. Jeśli wpiszesz end lub dead w typowej dystrybucji, najpewniej dostaniesz komunikat w stylu command not found, chyba że ktoś lokalnie utworzył taki skrypt lub alias. Null też nie służy do kończenia procesów. W systemach Unix/Linux pojęcie null najczęściej kojarzy się z urządzeniem specjalnym /dev/null, czyli miejscem, do którego można przekierować niepotrzebne dane wyjściowe, np. komunikaty programu. To „czarna dziura” dla danych, a nie mechanizm zarządzania procesami. Poprawnym narzędziem jest kill, ponieważ wysyła do procesu sygnał, najczęściej SIGTERM, a w razie potrzeby SIGKILL. W praktyce administrator najpierw ustala PID procesu poleceniami ps, top, htop albo pgrep, a dopiero potem kończy go w kontrolowany sposób. Z mojego doświadczenia lepiej nie używać kill -9 na ślepo, bo można przerwać zapis danych albo zostawić aplikację w nieładnym stanie. Dobre nawyki w Linuxie polegają na rozumieniu sygnałów i działania procesów, a nie tylko na zapamiętaniu pojedynczej komendy.