signal
NAZWA
signal - lista dostępnych sygnałów
OPIS
Linux wspiera zarówno rzeczywiste sygnały POSIX-owe (zwane dalej
"sygnałami standardowymi"), jak i sygnały POSIX-owe czasu rzeczywis-
tego.
Zachowania sygna�łu
Każdy sygnał ma przypisane bieżące zachowanie, które określa reakcję
procesu na dostarczony sygnał.
Wpisy w kolumnie "Akcja" tabeli określają domyślne zachowanie dla
danego sygnału, jako jedno z następujących:
Term Domyślną akcją jest przerwanie procesu.
Ign Domyślną akcją jest zignorowanie sygnału.
Core Domyślną akcją jest przerwanie procesu i zapisanie obrazu
pamięci (patrz core(5)).
Stop Domyślną akcją jest zatrzymanie procesu.
Cont Domyślną akcją jest kontynuowanie procesu, jeżeli jest obecnie
zatrzymany.
Proces może zmienić zachowanie się sygnału, używając sigaction(2) lub
(mniej przenośnego) signal(2). Używając tych wywołań systemowych, pro-
ces może wybrać jedną z poniższych reakcji na dostarczenie sygnału:
wykonać domyślną akcję, zignorować sygnał, przejąć sygnał wykonując
akcję obsługi sygnału, czyli podaną przez programistę funkcję,
wywoływaną automatycznie po dostarczeniu sygnału.
Zachowanie sygnału jest atrybutem poszczególnych procesów: w aplikacji
wielowątkowej zachowanie danego sygnału jest takie samo dla wszystkich
wątków.
Maska sygna�łu i sygna�ły oczekuj�ące
Sygnał może być zablokowany, co oznacza, że nie zostanie dostarczony,
dopóki się go nie odblokuje. Sygnał jest nazywany oczekującym, jeżeli
został już wygenerowany, ale nie został jeszcze dostarczony.
Każdy wątek procesu ma swoją niezależną maskę sygnałów, określającą
zbiór sygnałów obecnie blokowanych przez wątek. Wątek może zmieniać
maskę sygnałów, używając pthread_sigmask(3). Tradycyjna, jednowątkowa
aplikacja może do tego celu użyć sigprocmask(2).
Sygnał może być wygenerowany (i w związku z tym oczekujący) dla procesu
jako całości (np. wysłany za pomocą kill(2)) lub dla określonego wątku
(np. skierowane do wątku są niektóre sygnały, takie jak SIGSEGV lub
SIGPFPE, generowane w konsekwencji użycia określonej instrukcji języka
maszynowego oraz sygnały wysłane za pomocą pthread_kill(2)). Sygnał
skierowany do procesu może być dostarczony do któregokolwiek z jego
wątków, który nie blokuje tego sygnału. Jeżeli więcej niż jeden wątek
nie blokuje sygnału, to jądro dostarczy sygnał do przypadkowo wybranego
wątku.
Wątek może pobrać zbiór obecnie oczekujących sygnałów, używając sig-
pending(2). Zbiór ten będzie zawierał sygnały oczekujące skierowane
zarówno do całego procesu, jak i do wywołującego wątku.
Sygna�ły standardowe
Linux wspiera wymienione poniżej sygnały standardowe. Numery niektórych
sygnałów zależą od architektury, co pokazano w kolumnie "Wartość".
(Jeżeli podano trzy wartości, to zazwyczaj pierwsza obowiązuje dla
architektur alpha i sparc, środkowa dla i386, ppc i sh, a ostatnia dla
mips. Znak - oznacza, że sygnał dla danej architektury nie występuje.)
Najpierw sygnały opisane w pierwotnym standardzie POSIX.1.
Sygnał Wartość Akcja Komentarz
-----------------------------------------------------------------------------
SIGHUP 1 Term Zawieszenie wykryte na terminalu kontrolującym
lub śmierć procesu kontrolującego
SIGINT 2 Term Przerwanie nakazane z klawiatury
SIGQUIT 3 Core Wyjście nakazane z klawiatury
SIGILL 4 Core Nielegalna instrukcja
SIGABRT 6 Core Sygnał abort od abort(3)
SIGFPE 8 Core Wyjątek zmiennoprzecinkowy
SIGKILL 9 Term Sygnał Kill
SIGSEGV 11 Core Nieprawidłowa referencja pamięciowa
SIGPIPE 13 Term Uszkodzony potok: zapis do potoku bez odbiorców
SIGALRM 14 Term Sygnał timera od alarm(2)
SIGTERM 15 Term Sygnał zakończenia pracy
SIGUSR1 30,10,16 Term Sygnał 1 użytkownika
SIGUSR2 31,12,17 Term Sygnał 2 użytkownika
SIGCHLD 20,17,18 Ign Potomek zatrzymał się lub zakończył pracę
SIGCONT 19,18,25 Cont Kontynuuj, jeśli się zatrzymał
SIGSTOP 17,19,23 Stop Zatrzymaj proces
SIGTSTP 18,20,24 Stop Zatrzymanie napisane z tty
SIGTTIN 21,21,26 Stop Wejście tty dla procesu w tle
SIGTTOU 22,22,27 Stop Wyjście tty dla procesu w tle
Sygnałów SIGKILL oraz SIGSTOP nie można przechwycić, zablokować ani
zignorować.
Następnie sygnały nie występujące w standardzie POSIX.1, ale opisane w
SUSv2 lub w SUSv3 / POSIX 1003.1-2001.
Sygnał Wartość Akcja Komentarz
----------------------------------------------------------------------------------
SIGBUS 10,7,10 Core Błąd szyny (nieprawidłowy dostęp do pamięci)
SIGPOLL Term Zdarzenie odpytywalne (Sys V). Synonim SIGIO
SIGPROF 27,27,29 Term Przeterminowanie zegara profilowego
SIGSYS 12,-,12 Core Niewłaściwy argument funkcji (SVID)
SIGTRAP 5 Core Śledzenie/pułapka kontrolna
SIGURG 16,23,21 Ign Pilny warunek na gnieździe (BSD 4.2)
SIGVTALRM 26,26,28 Term Wirtualny zegar alarmu (BSD 4.2)
SIGXCPU 24,24,30 Core Przekroczone ograniczenie czasu CPU (BSD 4.2)
SIGXFSZ 25,25,31 Core Przekroczone ograniczenie rozmiaru pliku (BSD 4.2)
Do wersji 2.2 Linuksa (włącznie) domyślne zachowanie dla sygnałów
SIGSYS, SIGXCPU, SIGXFSZ oraz (na architekturach innych niż SPARC i
MIPS) SIGBUS polegało na przerwaniu procesu (bez zrzutu pamięci). (W
niektórych innych Uniksach domyślne zachowanie dla SIGXCPU i SIGXFSZ
polega na przerwaniu procesu bez zrzutu pamięci). Linux 2.4 jest zgodny
ze wymaganiami standardu POSIX 1003.1-2001 w zakresie przerywania pro-
cesu ze zrzutem pamięci.
A teraz różne inne sygnały.
Sygnał Wartość Akcja Komentarz
---------------------------------------------------------------------------
SIGIOT 6 Core pułapka IOT. Synonim SIGABRT
SIGEMT 7,-,7 Term
SIGSTKFLT -,16,- Term Błąd stosu koprocesora (nieużywany)
SIGIO 23,29,22 Term I/O teraz możliwe (BSD 4.2)
SIGCLD -,-,18 Ign Synonim SIGCHLD
SIGPWR 29,30,19 Term Błąd zasilania (System V)
SIGINFO 29,-,- Synonim SIGPWR
SIGLOST -,-,- Term Utracono blokadę pliku
SIGWINCH 28,28,20 Ign Sygnał zmiany rozmiarów okna (BSD 4.3, Sun)
SIGUNUSED -,31,- Term Nie użyty sygnał (wystąpi SIGSYS)
(Sygnał 29 oznacza SIGINFO / SIGPWR na architekturze alpha, lecz
SIGLOST na architekturze sparc).
SIGEMT nie jest wymieniony w POSIX 1003.1-2001, lecz pomimo to pojawia
się w większości innych Uniksów. Domyślną akcją dla tego sygnału jest
zazwyczaj przerwanie procesu ze zrzutem pamięci.
SIGPWR (nie wymieniony w POSIX 1003.1-2001) jest zazwyczaj domyślnie
ignorowany w tych Uniksach, w których występuje.
SIGIO (nie wymieniony w POSIX 1003.1-2001) jest domyślnie ignorowany w
niektórych innych Uniksach.
Sygna�ły czasu rzeczywistego
Linux wspiera sygnały czasu rzeczywistego zdefiniowane pierwotnie w
rozszerzeniu dla czasu rzeczywistego POSIX.4 (a obecnie zawarte w POSIX
1003.1-2001). Linux wspiera 32 sygnały czasu rzeczywistego, o numerach
od 32 (SIGRTMIN) do 63 (SIGRTMAX). (Programy powinny zawsze odwoływać
się do sygnałów czasu rzeczywistego używając notacji SIGRTMIN+n, gdyż
zakres numerów sygnałów czasu rzeczywistego różni się pomiędzy
Uniksami).
W odróżnieniu od sygnałów standardowych, sygnały czasu rzeczywistego
nie posiadają predefiniowanego znaczenia: można wykorzystywać cały
zestaw sygnałów czasu rzeczywistego do celów określonych w aplikacji.
(Należy jednak zauważyć, że implementacja LinuxThreads korzysta z
trzech pierwszych sygnałów czasu rzeczywistego).
Domyślą akcją na nieobsłużony sygnał czasu rzeczywistego jest przer-
wanie procesu, który go otrzymał.
Sygnały czasu rzeczywistego są rozpoznawane w następujący sposób:
1. Można kolejkować wiele egzemplarzy sygnału czasu rzeczywistego. Dla
odróżnienia, jeśli w czasie gdy standardowy sygnał jest blokowany
zostanie doręczonych wiele egzemplarzy tego sygnału, tylko jeden
egzemplarzy trafia do kolejki.
2. Jeśli sygnał wysłano korzystając z sigqueue(2), można wysłać wraz z
tym sygnałem wartość towarzyszącą (całkowitą lub wskaźnik). Jeśli
proces otrzymujący ustanawia funkcję obsługi dla tego sygnału za
pomocą znacznika SA_SIGACTION funkcji sigaction(2), to otrzymuje
towarzyszącą mu daną za pośrednictwem pola si_value struktury sig-
info_t przekazanej jako drugi argument funkcji obsługi. Ponadto,
pola si_pid oraz si_uid tej struktury mogą służyć do otrzymania PID
oraz rzeczywistego ID użytkownika procesu wysyłającego sygnał.
3. Sygnały czasu rzeczywistego są doręczane w zagwarantowanej kole-
jności. Sygnały czasu rzeczywistego jednego rodzaju są doręczane w
takiej kolejności, w jakiej zostały wysłane. Jeśli do procesu
zostaną wysłane różne sygnały czasu rzeczywistego, będą one
doręczone począwszy od sygnału o najniższym numerze. (Tzn. sygnały
o niskich numerach mają najwyższy priorytet).
POSIX nie określa, które z sygnałów powinny zostać doręczone jako pier-
wsze w sytuacji, gdy obsłużenia wymagają zarówno sygnały standardowe,
jak i sygnały czasu rzeczywistego. Linux, podobnie do innych implemen-
tacji, daje w tym przypadku pierwszeństwo sygnałom standardowym.
Zgodnie z POSIX, implementacja powinna zezwalać na kolejkowanie do pro-
cesu co najmniej _POSIX_SIGQUEUE_MAX (32) sygnałów czasu rzeczywistego.
Jednakże, Linux zamiast określać ograniczenie dla procesu, wymusza
ograniczenie ogólnosystemowe liczby kolejkowanych do wszystkich pro-
cesów sygnałów czasu rzeczywistego. Ograniczenie to można zobaczyć, a
także (przy odpowiednich uprawnieniach) zmienić za pośrednictwem pliku
/proc/sys/kernel/rtsig-max. Podobnie, za pośrednictwem pliku
/proc/sys/kernel/rtsig-nr można dowiedzieć się ile sygnałów czasu
rzeczywistego jest aktualnie w kolejce. W Linuksie 2.6.8 ten interfejs
/proc został zastąpiony limitem zasobów RLIMIT_SIGPENDING, który
określa limit kolejkowanych sygnałów dla poszczególnych użytkowników;
patrz setrlimit(2) w celu uzyskania dalszych informacji.
ZGODNE Z
POSIX.1
B�Ł�ĘDY
SIGIO i SIGLOST mają tę samą wartość. Ten drugi jest zakomentowany w
źródłach jądra, lecz proces tworzenia niektórych aplikacji wciąż
zakłada, że sygnał 29 to SIGLOST.
ZOBACZ TAKŻE
kill(1), kill(2), killpg(2), setitimer(2), setrlimit(2), sigaction(2),
signal(2), sigpending(2), sigprocmask(2), sigqueue(2), sigsuspend(2),
sigwaitinfo(2), raise(3), sigvec(3), sigset(3), strsignal(3), core(5),
proc(5), pthreads(7)