SIGKILL

Sygnał (numer 9) natychmiast i bezwarunkowo kończący proces. Nie da się go przechwycić ani zignorować, więc używa się go do ubicia zawieszonych programów.

SIGKILL to sygnał systemowy w Uniksie i Linuksie o numerze 9, którego jedynym zadaniem jest natychmiastowe i bezwarunkowe zakończenie procesu. Jego wyjątkowość polega na tym, że proces nie ma nad nim żadnej kontroli: nie da się go przechwycić (catch), zablokować (block) ani zignorować. Kiedy SIGKILL trafia do procesu, decyzję podejmuje jądro systemu, a nie sam program — i ta decyzja brzmi zawsze tak samo: koniec, teraz.

Jak to działa i do czego służy

Większość sygnałów w Linuksie to grzeczna prośba. SIGTERM (numer 15) mówi procesowi „zakończ się, kiedy będziesz gotowy” i pozwala mu posprzątać: zamknąć pliki, zapisać dane, zwolnić blokady. SIGKILL takiej uprzejmości nie zna. Jądro po prostu usuwa proces z systemu, nie dając mu ani chwili na reakcję. Dlatego właśnie SIGKILL razem z SIGSTOP należą do dwóch jedynych sygnałów, których nie można obsłużyć własnym handlerem.

Używasz go wtedy, gdy normalne metody zawiodły: program się zawiesił, wpadł w nieskończoną pętlę, ignoruje SIGTERM albo zżera całą pamięć. To opcja „awaryjnego hamulca”, a nie codzienny sposób zamykania aplikacji.

Przykład z praktyki

Masz zawieszony proces o PID 4242, który nie reaguje na nic. Najpierw spróbuj grzecznie:

  • kill 4242 — wysyła domyślnie SIGTERM,
  • kill -9 4242 lub kill -SIGKILL 4242 — gdy SIGTERM nie pomógł,
  • pkill -9 nazwa_procesu — gdy chcesz ubić po nazwie.

Komenda kill wbrew nazwie nie „zabija” — ona wysyła sygnał. To, czy proces zginie, zależy od sygnału. Dopiero -9 gwarantuje skutek.

Częste błędy i mity

Najczęstszy odruch nowicjusza to kill -9 jako pierwszy strzał. To zły nawyk. Skoro proces nie dostaje szansy na sprzątanie, zostawia za sobą bałagan: niezapisane dane, uszkodzone pliki, osierocone blokady, procesy potomne bez rodzica (tzw. orphans). Zawsze zaczynaj od SIGTERM, a po SIGKILL sięgaj dopiero, gdy łagodniejszy sygnał nie zadziała.

Drugi mit: „SIGKILL ubije wszystko”. Nie zawsze. Proces zablokowany w stanie D (uninterruptible sleep), zwykle czekający na operację I/O, zignoruje nawet SIGKILL, bo jądro nie może mu go w danej chwili dostarczyć. Wtedy nie pomoże nic poza usunięciem przyczyny blokady lub restartem.

Trzecia pułapka: kill -9 1 nie zrestartuje systemu — proces o PID 1 (init/systemd) jest na to odporny.

Pojęcia powiązane: SIGTERM, SIGSTOP, SIGINT, signal, proces, PID, polecenia kill, pkill, killall, stan procesu D (uninterruptible sleep), proces zombie.