SIGNAL(7)

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 rzeczywistego.

  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, proces 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 sigpending(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 procesu 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 przerwanie 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 siginfo_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 kolejnoś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 pierwsze w sytuacji, gdy obsłużenia wymagają zarówno sygnały standardowe, jak i sygnały czasu rzeczywistego. Linux, podobnie do innych implementacji, daje w tym przypadku pierwszeństwo sygnałom standardowym.

Zgodnie z POSIX, implementacja powinna zezwalać na kolejkowanie do procesu 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 procesó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)