Jeśli w Unixwierszu poleceń naciśniemy Ctrl-C, nie kończy to procesu, ale raczej go przerywa i wracam do wiersza poleceń powłoki.
Mam więc następujące dwa pytania:
Odpowiedzi:
Ctrl+ Cwysyła a SIGINT. Domyślnie powoduje to zamknięcie aplikacji.
Mylisz to z Ctrl-Z, co powoduje zawieszenie aplikacji w bash.
Historycznie istniały trzy sygnały związane z naciśnięciami klawiszy
W niektórych smakach * nix są również powiązane inne sygnały, możesz sprawdzić powiązania klawiatury za pomocą polecenia
stty -a
W moim systemie OS / X generuje to następujące dane wyjściowe
speed 9600 baud; 65 rows; 213 columns;
lflags: icanon isig iexten echo echoe -echok echoke -echonl echoctl
-echoprt -altwerase -noflsh -tostop -flusho pendin -nokerninfo
-extproc
iflags: -istrip icrnl -inlcr -igncr ixon -ixoff ixany imaxbel iutf8
-ignbrk brkint -inpck -ignpar -parmrk
oflags: opost onlcr -oxtabs -onocr -onlret
cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -dsrflow
-dtrflow -mdmbuf
cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = <undef>;
eol2 = <undef>; erase = ^?; intr = ^C; kill = ^U; lnext = ^V;
min = 1; quit = ^\; reprint = ^R; start = ^Q; status = ^T;
stop = ^S; susp = ^Z; time = 0; werase = ^W;
Uwaga: zabójstwo w tym przypadku nie jest sygnałem KILL, który ma związek z czyszczeniem bieżącego bufora wejściowego.
Możesz mieć większy sukces w zatrzymywaniu procesów za pomocą SIGQUIT, ale może nie być to prawdą, ponieważ proces może przechwycić sygnał i zignorować go.
Nie ma koncepcji listy „przerwanych” procesów, ponieważ proces albo wychwycił i zignorował przerwanie, albo zakończył działanie. Możesz uzyskać listę zawieszonych procesów, wpisując zadania
Wiele poprawnych odpowiedzi, ale nie są kompletne.
Aby zakończyć działanie z najwyższymi uprzedzeniami i bez pozwalania na zatrzymanie procesu, użyj SIGKILL, który domyślnie nie jest powiązany z żadnym kluczem. Zamiast tego generalnie wysyłasz go za pomocą kill (1)polecenia i podając sygnał do wysłania jak za
$ kill -9 <process ID>
lub mnemonicznie
$ kill -KILL <process ID>
Ten sygnał jest obsługiwany bezpośrednio przez system operacyjny i program nie może zastąpić domyślnego zachowania.
Jeśli twoja powłoka obsługuje kontrolę zadań, może również obsługiwać wbudowaną wersję, killktóra obsługuje identyfikację zadań za pomocą %znaku jak w odpowiedzi na wybiegu .
fgaby albo kontynuować kontrolę nad terminalem, albo bgustawić go na działanie bez utrzymywania kontroli nad terminalem (ale domyślnie nadal wysyła tam swoje dane wyjściowe).aby zobaczyć listę procesów w tle: jobs
to kill: kill %1(zastąp 1 odpowiednim identyfikatorem zadania jak na jobswyjściu)
Ctrl-C wysyła SIGINT, który domyślnie powoduje zakończenie procesu, ale może zostać uwięziony (w \bin sh, za pomocą trap).
SIGKILL to niezniszczalny sygnał zabicia.
Edytuj Po raz trzeci myślę, że to prawda: sprawdziłem wszystko pod kątem dokumentów. Zobaczymy.
Dla większości początkujących nie jest to jasne, ale jeśli Twoim problemem jest to, że jesteś w programie interaktywnym i nie możesz dowiedzieć się, jak się wydostać, dość często qwychodzi. Na przykład jest to klucz do wyjścia less, który jest także programem, który otrzymujesz manmiędzy innymi podczas przeglądania stron.
Niektóre programy mają inne skróty klawiaturowe do wyjścia. W vimlub viużyj ESC:wq. W emacs, użyj Control-C Control-X. W nanolub picoużyj Control-X. Zauważ, że w tych przykładach są subtelności, w szczególności dotyczące tego, czy te skróty zapisują wszelkie zmiany, które możesz wprowadzić w edytowanym pliku.
Wiele procesów może zainstalować moduł obsługi przerwań w celu przechwycenia sygnału przerwania, ale te, które domyślnie się nie przerywają.
Aby wymusić zakończenie procesu, możesz wysłać SIGQUIT (Ctrl- \).
Wygląda na to, że inne odpowiedzi są prawdopodobnym scenariuszem, ale możliwe jest również, że wykonujesz skrypt, który nie obsługuje poprawnie swoich dzieci. Niedawno natrafiłem na podobny scenariusz, w którym zabicie skryptu nie zabiłoby procesów potomnych tego skryptu.
Ogólnie rzecz biorąc, jeśli znajdziesz się w tej sytuacji, będziesz musiał przejrzeć wszystkie uruchomione procesy. Powinieneś przejrzeć manpage dla ps. ( man ps) Szczególnie podoba mi się używanie ps auxwf, które pokazuje relacje rodzic / dziecko między procesami. pstreerobi coś podobnego. Powinieneś uruchomić to z innego terminala przed zabiciem procesu, aby zobaczyć, jak wygląda sytuacja w normalnej sytuacji i zidentyfikować procesy potomne.
Jeśli następnie zabijesz (za pomocą ^ C) ten główny proces, sprawdź ponownie wyjście ps, aby zobaczyć, czy coś się zmieniło. Jeśli procesy potomne nadal istnieją, możesz je zabić za pomocą killpolecenia. (patrz man kill)
stty -ixontak, aby były przekazywane. Myślałbym, że zmieniliby się na<undef>.