.\" -*- coding: UTF-8 -*-
'\" t
.\" Copyright (c) 1993 by Thomas Koenig (ig25@rz.uni-karlsruhe.de)
.\" and Copyright (c) 2002, 2006, 2020 by Michael Kerrisk <mtk.manpages@gmail.com>
.\" and Copyright (c) 2008 Linux Foundation, written by Michael Kerrisk
.\"     <mtk.manpages@gmail.com>
.\"
.\" SPDX-License-Identifier: Linux-man-pages-copyleft
.\"
.\" Modified Sat Jul 24 17:34:08 1993 by Rik Faith (faith@cs.unc.edu)
.\" Modified Sun Jan  7 01:41:27 1996 by Andries Brouwer (aeb@cwi.nl)
.\" Modified Sun Apr 14 12:02:29 1996 by Andries Brouwer (aeb@cwi.nl)
.\" Modified Sat Nov 13 16:28:23 1999 by Andries Brouwer (aeb@cwi.nl)
.\" Modified 10 Apr 2002, by Michael Kerrisk <mtk.manpages@gmail.com>
.\" Modified  7 Jun 2002, by Michael Kerrisk <mtk.manpages@gmail.com>
.\"	Added information on real-time signals
.\" Modified 13 Jun 2002, by Michael Kerrisk <mtk.manpages@gmail.com>
.\"	Noted that SIGSTKFLT is in fact unused
.\" 2004-12-03, Modified mtk, added notes on RLIMIT_SIGPENDING
.\" 2006-04-24, mtk, Added text on changing signal dispositions,
.\"		signal mask, and pending signals.
.\" 2008-07-04, mtk:
.\"     Added section on system call restarting (SA_RESTART)
.\"     Added section on stop/cont signals interrupting syscalls.
.\" 2008-10-05, mtk: various additions
.\"
.\"*******************************************************************
.\"
.\" This file was generated with po4a. Translate the source file.
.\"
.\"*******************************************************************
.TH signal 7 "2 maja 2024 r." "Linux man\-pages 6.8" 
.SH NAZWA
signal \- przegląd sygnałów
.SH OPIS
Linux wspiera zarówno rzeczywiste sygnały POSIX\-owe (zwane dalej
\[Bq]sygnałami standardowymi\[rq]), jak i sygnały POSIX\-owe czasu
rzeczywistego.
.SS "Zachowania sygnału"
Każdy sygnał ma przypisane bieżące \fIzachowanie\fP, które określa reakcję
procesu na dostarczony sygnał.
.P
Wpisy w kolumnie \[Bq]Akcja\[rq] tabel określają domyślne zachowanie dla
danego sygnału, jako jedno z następujących:
.TP 
Term
Domyślną akcją jest przerwanie procesu.
.TP 
Ign
Domyślną akcją jest zignorowanie sygnału.
.TP 
Core
Domyślną akcją jest przerwanie procesu i zapisanie obrazu pamięci (patrz
\fBcore\fP(5)).
.TP 
Stop
Domyślną akcją jest zatrzymanie procesu.
.TP 
Cont
Domyślną akcją jest kontynuowanie procesu, jeżeli jest obecnie zatrzymany.
.P
Proces może zmienić zachowanie się sygnału, używając \fBsigaction\fP(2) lub
\fBsignal\fP(2) (to drugie jest mniej przenośne, jeśli chodzi o ustawianie
akcji obsługi sygnału; szczegóły opisano w \fBsignal\fP(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 \fIprocedurę obsługi sygnału\fP, czyli podaną przez
programistę funkcję, wywoływaną automatycznie po dostarczeniu sygnału.
.P
Domyślnie procedura obsługi sygnału jest uruchamiana na normalnym stosie
procesu. Można to zmienić, tak żeby używany był stos alternatywny;
szczegóły, jak i po co to robić, można znaleźć w \fBsigaltstack\fP(2)
.P
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.
.P
Potomek utworzony przez \fBfork\fP(2) dziedziczy kopię ustawień sygnałów od
swojego rodzica. Podczas wywołania \fBexecve\fP(2) przywracane są wartości
domyślne ustawień, z wyjątkiem ustawienia ignorowania sygnału, które nie
jest zmieniane.
.SS "Wysyłanie sygnału"
Następujące wywołania systemowe lub funkcje biblioteczne umożliwiają
wysyłanie sygnałów:
.TP 
\fBraise\fP(3)
Wysyła sygnał do wątku, który wywołał tę funckję.
.TP 
\fBkill\fP(2)
Wysyła sygnał do podanego procesu lub do wszystich członków podanej grupy
procesów, lub do wszystkich procesów w systemie.
.TP 
\fBpidfd_send_signal\fP(2)
Wysyła sygnał do procesu identyfikowanego za pomocą deskryptora pliku PID.
.TP 
\fBkillpg\fP(3)
Wysyła sygnał do wszystkich członków podanej grupy procesów.
.TP 
\fBpthread_kill\fP(3)
Wysyła sygnał do podanego wątku POSIX w tym samym procesie, co proces
wywołujący.
.TP 
\fBtgkill\fP(2)
Wysyła sygnał do podanego wątku w podanym procesie (jest to używane do
zaimplementowania  \fBpthread_kill\fP(3)).
.TP 
\fBsigqueue\fP(3)
Wysyła sygnał czasu rzeczywistego wraz z powiązanymi danymi do podanego
procesu.
.SS "Oczekiwanie na przechwycenie sygnału"
Następujące wywołania systemowe zawieszają wykonywanie wywołującego je wątku
do momentu obsłużenia sygnału (lub do momentu, w którym nieobsłużony sygnał
spowoduje zakończenie procesu).
.TP 
\fBpause\fP(2)
Zawiesza wykonywanie do momentu złapania sygnału.
.TP 
\fBsigsuspend\fP(2)
.\"
Tymczasowo zmienia maskę sygnału (patrz niżej) i zawiesza wykonywanie do
momentu przechwycenia  jednego z niemaskowanych sygnałów.
.SS "Synchroniczne akceptowanie sygnału"
Zamiast asynchronicznego przechwytywania sygnału przez procedurę jego
obsługi, możliwe jest synchroniczne akceptowanie sygnałów, czyli blokowanie
wykonywania do czasu dostarczenia sygnału, w którym to momencie jądro zwraca
informacje o sygnale do funkcji wywołującej. W ogólności można to zrobić na
dwa sposoby:
.IP \[bu] 3
\fBsigwaitinfo\fP(2), \fBsigtimedwait\fP(2) oraz \fBsigwait\fP(3) zawieszają
wykonanie aż do chwili dostarczenia jednego z sygnałów należącego do
podanego zbioru sygnałów. Każde z tych wywołań systemowych zwraca informacje
o dostarczonym sygnale.
.IP \[bu]
\fBsignalfd\fP(2) zwraca deskryptor pliku, którego można użyć do odczytania
informacji o sygnałach dostarczanych do procesu wywołującego. Każda operacja
odczytu za pomocą \fBread\fP(2) z tego deskryptora pliku jest blokowana do
czasu dostarczenia do programu wywołującego jednego z sygnałów przekazanych
w zbiorze \fBsignalfd\fP(2). Bufor zwracany przez \fBread\fP(2) zawiera strukturę
opisującą sygnał.
.SS "Maska sygnału i sygnały oczekujące"
Sygnał może być \fIzablokowany\fP, co oznacza, że nie zostanie dostarczony,
dopóki się go nie odblokuje. Sygnał jest nazywany \fIoczekującym\fP, jeżeli
został już wygenerowany, ale nie został jeszcze dostarczony.
.P
Każdy wątek procesu ma swoją niezależną \fImaskę sygnałów\fP, określającą zbiór
sygnałów obecnie blokowanych przez wątek. Wątek może zmieniać maskę
sygnałów, używając \fBpthread_sigmask\fP(3). Tradycyjna, jednowątkowa aplikacja
może do tego celu użyć \fBsigprocmask\fP(2).
.P
Dziecko utworzone przez \fBfork\fP(2) dziedziczy kopię maski sygnałów od
swojego rodzica. Maska jest zachowywana podczas wywołań \fBexecve\fP(2).
.P
Sygnał może być kierowany do procesu lub kierowany do wątku. Sygnał
kierowany do procesu jest przeznaczony do (i oczekujący wobec) całego
procesu. Sygnał może być kierowany do procesu, ponieważ został wygenerowany
przez jądro, z powodów innych niż wyjątek sprzętowy albo ponieważ został
wysłany za pomocą \fBkill\fP(2) lub \fBsigqueue\fP(3). Sygnał kierowany do wątku
jest przeznaczony do konkretnego wątku. Sygnał może być kierowany do wątku,
ponieważ został wygenerowany w konsekwencji wykonania specjalnej instrukcji
języka maszynowego, która wyzwoliła wyjątek sprzętowy (np. \fBSIGSEGV\fP w
przypadku nieprawidłowego dostępu do pamięci lub \fBSIGFPE\fP w przypadku błędu
matematycznego) albo ponieważ jest kierowany do konkretnego wątku poprzez
interfejs taki jak \fBtgkill\fP(2) lub \fBpthread_kill\fP(3).
.P
.\" Joseph C. Sible notes:
.\" On Linux, if the main thread has the signal unblocked, then the kernel
.\" will always deliver the signal there, citing this kernel code
.\"
.\"     Per this comment in kernel/signal.c since time immemorial:
.\"
.\"     /*
.\"     * Now find a thread we can wake up to take the signal off the queue.
.\"     *
.\"     * If the main thread wants the signal, it gets first crack.
.\"     * Probably the least surprising to the average bear.
.\"     */
.\"
.\" But this does not mean the signal will be delivered only in the
.\" main thread, since if a handler is already executing in the main thread
.\" (and thus the signal is blocked in that thread), then a further
.\" might be delivered in a different thread.
.\"
Sygnał kierowany do procesu może być dostarczony do dowolnego z wątków,
który aktualnie nie blokuje sygnału. Jeśli więcej niż jeden wątków ma
odblokowany sygnał, jądro wybiera wątek, do którego zostanie dostarczony
sygnał, w sposób dowolny.
.P
Wątek może pobrać zbiór obecnie oczekujących sygnałów, używając
\fBsigpending\fP(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.
.P
.\"
Zbiór sygnałów oczekujących dziecka utworzonego przez \fBfork\fP(2) jest na
samym początku pusty. Zbiór ten jest zachowywany podczas \fBexecve\fP(2).
.SS "Wykonanie procecedur obsługi sygnałów"
Gdy tylko zachodzi przejście wykonania z trybu jądra do trybu użytkownika
(np. powrót z wywołania systemowego lub zakolejkowanie wątku do procesora)
jądra sprawdza, czy występuje oczekujący, niezablokowany sygnał, dla którego
proces ustanowił procedurę obsługi sygnału. Jeśli taki oczekujący sygnał
występuje, mają miejsce poniższe kroki:
.IP (1) 5
Jądro przeprowadza niezbędne działania przygotowawcze do wykonania procedury
obsługi sygnału:
.RS
.IP (1.1) 7
Sygnał jest usuwany ze zbioru oczekujących sygnałów.
.IP (1.2)
Jeśli sygnał został zainstalowany wywołaniem do \fBsigaction\fP(2) ze
znacznikiem \fBSA_ONSTACK\fP oraz wątek zdefiniował alternatywny stos sygnałów
(za pomocą \fBsigaltstack\fP(2)) \[em] stos ten jest instalowany.
.IP (1.3)
Różne części kontekstu związanego z sygnałem są zapisywane do specjalnej
ramki, która jest tworzona na stosie. Zapisywane informacje obejmują:
.RS
.IP \[bu] 3
Rejestr licznika rozkazów (tj. adres następnej instrukcji w głównym
programie, która powinna być wykonana po powrocie z procedury obsługi
sygnału);
.IP \[bu]
Stan rejestru zależny od architektury, wymagany do wznowienia przerwanego
programu;
.IP \[bu]
bieżąca maska sygnałów wątku;
.IP \[bu]
ustawienia alternatywnego stosu sygnałów wątku.
.RE
.IP
(Jeśli procedurę obsługi sygnału zainstalowano przy użyciu znacznika
\fBSA_SIGINFO\fP \fBsigaction\fP(2), powyższe informacje są dostępne za pomocą
obiektu \fIucontext_t\fP, na który wskazuje trzeci argument procedury obsługi
sygnału).
.IP (1.4)
Wszelkie sygnały podane w \fIact\->sa_mask\fP przy rejestracji procedury
obsługi przy użyciu \fBsigprocmask\fP(2) są dodawane do maski sygnałów
wątku. Dostarczany sygnał jest również dodawany do maski sygnałów, chyba że
przy rejestracji procedury obsługi podano \fBSA_NODEFER\fP. Z tego powodu, te
sygnały są blokowane w trakcie wykonywania procedury obsługi.
.RE
.IP (2)
Jądro tworzy ramkę na stosie, dla procedury obsługi sygnału. Jądro ustawia
licznik rozkazów dla wątku tak, aby wskazywał na pierwszą instrukcję funkcji
obsługi sygnału i konfiguruje adres powrotny dla tej funkcji tak, aby
wskazywał na kod w przestrzeni użytkownika znany jako trampolina sygnału
(opisany w podręczniku \fBsigreturn\fP(2)).
.IP (3)
Jądro zwraca kontrolę do przestrzeni użytkownika, gdzie wykonanie zaczyna
się na początku funkcji obsługi sygnału.
.IP (4)
Gdy procedura obsługi sygnału powróci, kontrola jest przekazywana do kodu
trampoliny sygnału.
.IP (5)
Trampolina sygnału wywołuje \fBsigreturn\fP(2), wywołanie systemowe, które za
pomocą informacji w ramce stosu utworzonej w kroku 1, przywraca wątek do
stanu sprzed wywołania procedury obsługi sygnału. Jako część tej procedury,
przywracana jest maska sygnałów wątku oraz ustawienia alternatywnego stosu
sygnałów. Po zakończeniu wywołania \fBsigreturn\fP(2), jądro przekazuje
kontrolę z powrotem do przestrzeni użytkownika, a wątek zaczyna wykonanie w
punkcie, w którym był przerwany procedurą obsługi sygnału.
.P
Proszę zauważyć, że jeśli procedura obsługi sygnału nie powróci
(np. kontrola zostanie przekazana poza procedurę obsługi za pomocą
\fBsiglongjmp\fP(3) albo procedura obsługi wykona nowy program za pomocą
\fBexecve\fP(2)), to ostatni krok nie jest wykonywany. W szczególności, w
takich przypadkach to po stronie programisty leży odpowiedzialność za
przywrócenie stanu maski sygnałów (przy użyciu \fBsigprocmask\fP(2)), jeśli
pożądane jest odblokowanie sygnałów, które zostały zablokowane przy wejściu
do procedury obsługi sygnału (proszę zauważyć, że \fBsiglongjmp\fP(3) może, ale
nie musi przywrócić maski sygnałów, w zależności od wartości \fIsavesigs\fP
podanej w odpowiednim wywołaniu do \fBsigsetjmp\fP(3)).
.P
.\"
Z punktu widzenia jądra, wykonanie kodu procedury obsługi sygnału jest
identyczne jak wykonanie każdego innego kodu w przestrzeni
użytkownika. Oznacza to, że jądro nie zapisuje żadnych specjalnych
informacji o stanie wskazujących, że wątek jest aktualnie wykonywany w
procedurze obsługi sygnału. Wszystkie niezbędne informacje o stanie są
utrzymywane w rejestrach w przestrzeni użytkownika i stosie w przestrzeni
użytkownika. Głębokość zagnieżdżenia wywoływanych procedur obsługi sygnału
zależy zatem tylko od stosu w przestrzeni użytkownika (i rozsądnego projektu
oprogramowania!).
.SS "Sygnały standardowe"
Linux obsługuje sygnały standardowe wypisane niżej. Druga kolumna wskazuje
jaki standard (o ile w ogóle) określa sygnał: \[Bq]P1990\[rq] oznacza, że
sygnał był opisany w pierwotnym standardzie POSIX.1\-1990; \[Bq]P2001\[rq]
wskazuje, że sygnał dodano w SUSv2 i POSIX.1\-2001.
.TS
l c c l
____
lB c c l.
Sygnał	Standard	Akcja	Komentarz
SIGABRT	P1990	Core	Sygnał abort od \fBabort\fP(3)
SIGALRM	P1990	Term	Sygnał timera od \fBalarm\fP(2)
SIGBUS	P2001	Core	Błąd szyny (niepr. dostęp do pamięci)
SIGCHLD	P1990	Ign	Potomek zatrzymał się lub zakończył pracę
SIGCLD	\-	Ign	Synonim \fBSIGCHLD\fP
SIGCONT	P1990	Cont	Kontynuuj, jeśli się zatrzymał
SIGEMT	\-	Term	Pułapka emulatora
SIGFPE	P1990	Core	Wyjątek zmiennoprzecinkowy
SIGHUP	P1990	Term	Zawieszenie wykryte na terminalu kontrol.
			lub śmierć procesu kontrolującego
SIGILL	P1990	Core	Nielegalna instrukcja
SIGINFO	\-		Synonim \fBSIGPWR\fP
SIGINT	P1990	Term	Przerwanie nakazane z klawiatury
SIGIO	\-	Term	I/O teraz możliwe (4.2BSD)
SIGIOT	\-	Core	Pułapka IOT. Synonim \fBSIGABRT\fP
SIGKILL	P1990	Term	Sygnał Kill
SIGLOST	\-	Term	Utracono blokadę pliku (nieużywane)
SIGPIPE	P1990	Term	Uszkodzony potok: zapis do potoku bez
			odczytujących; zob. \fBpipe\fP(7)
SIGPOLL	P2001	Term	Zdarzenie odpytywalne (Sys V);
			synonim dla \fBSIGIO\fP
SIGPROF	P2001	Term	Przeterminowanie zegara profilowego
SIGPWR	\-	Term	Błąd zasilania (System V)
SIGQUIT	P1990	Core	Wyjście nakazane z klawiatury
SIGSEGV	P1990	Core	Nieprawidłowa referencja pamięciowa
SIGSTKFLT	\-	Term	Błąd stosu koprocesora (nieużywany)
SIGSTOP	P1990	Stop	Zatrzymaj proces
SIGTSTP	P1990	Stop	Zatrzymanie napisane z terminala
SIGSYS	P2001	Core	Nieprawidłowe wywołanie systemowe (SVr4);
			zob. też \fBseccomp\fP(2)
SIGTERM	P1990	Term	Sygnał zakończenia pracy
SIGTRAP	P2001	Core	Śledzenie/pułapka kontrolna
SIGTTIN	P1990	Stop	Wejście terminala dla procesu w tle
SIGTTOU	P1990	Stop	Wyjście terminala dla procesu w tle
SIGUNUSED	\-	Core	Synonimiczny z \fBSIGSYS\fP
SIGURG	P2001	Ign	Pilny warunek na gnieździe (4.2BSD)
SIGUSR1	P1990	Term	Sygnał 1 użytkownika
SIGUSR2	P1990	Term	Sygnał 2 użytkownika
SIGVTALRM	P2001	Term	Wirtualny zegar alarmu (4.2BSD)
SIGXCPU	P2001	Core	Przekroczone ogran. czasu CPU (4.2BSD)
			zob. \fBsetrlimit\fP(2)
SIGXFSZ	P2001	Core	Przekr. ogran. rozmiaru pliku (4.2BSD)
			zob. \fBsetrlimit\fP(2)
SIGWINCH	\-	Ign	Sygnał zmiany rozm. okna (4.3BSD, Sun)
.TE
.P
Sygnałów \fBSIGKILL\fP oraz \fBSIGSTOP\fP nie można przechwycić, zablokować ani
zignorować.
.P
Do wersji 2.2 Linuksa (włącznie) domyślne zachowanie dla sygnałów \fBSIGSYS\fP,
\fBSIGXCPU\fP, \fBSIGXFSZ\fP oraz (na architekturach innych niż SPARC i MIPS)
\fBSIGBUS\fP polegało na przerwaniu procesu (bez zrzutu pamięci). (W niektórych
innych Uniksach domyślne zachowanie dla \fBSIGXCPU\fP i \fBSIGXFSZ\fP polega na
przerwaniu procesu bez zrzutu pamięci). Linux 2.4 jest zgodny ze wymaganiami
standardu POSIX.1\-2001 dotyczącymi tych sygnałów i przerywa proces ze
zrzutem pamięci.
.P
\fBSIGEMT\fP nie jest wymieniony w POSIX.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.
.P
\fBSIGPWR\fP (niewymieniony w POSIX.1\-2001) jest zazwyczaj domyślnie ignorowany
w tych Uniksach, w których występuje.
.P
.\"
\fBSIGIO\fP (niewymieniony w POSIX.1\-2001) jest domyślnie ignorowany w
niektórych innych Uniksach.
.SS "Kolejkowanie i semantyka dostarczania sygnałów standardowych"
Jeśli na proces oczekuje kilka sygnałów standardowych, kolejność, w jakiej
zostaną dostarczone, jest nieokreślona.
.P
.\"
Sygnały standardowe nie są kolejkowane. Jeśli w trakcie blokowania sygnału
wygenerowane zostanie wiele wystąpień sygnału standardowego, to tylko jedno
jego wystąpienie jest oznaczane jako oczekujące (i po jego odblokowaniu,
sygnał zostanie dostarczony jeden raz). W przypadku, gdy istnieje już sygnał
oczekujący, struktura \fIsiginfo_t\fP (zob. \fBsigaction\fP(2)) związana z danym
sygnałem nie jest nadpisywana, po nadejściu kolejnych wystąpień tego samego
sygnału. Proces otrzyma zatem informacje powiązane z pierwszym występieniem
danego sygnału.
.SS "Numerowanie sygnałów, w zakresie sygnałów standardowych"
Wartość numeryczna każdego sygnału jest podana w poniższej tabeli. Jak
wskazano w tabeli, wiele sygnałów ma zróżnicowane wartości numeryczne na
różnych architekturach. Pierwsza wartość numeryczna w każdym wierszu tabeli
ukazuje numer sygnału na architekturze x86, ARM i większości innych
architektur; druga wartość dotyczy Alpha i SPARC; trzecia \[em] MIPS; a
ostatnia \[em] PARISC. Kreska (\-) wskazuje, że sygnał nie występuje na danej
architekturze.
.TS
l c c c c l
l c c c c l
______
lB c c c c l.
Sygnał	x86/ARM	Alpha/	MIPS	PARISC	Uwagi
	większość innych	SPARC
SIGHUP	\01	\01	\01	\01
SIGINT	\02	\02	\02	\02
SIGQUIT	\03	\03	\03	\03
SIGILL	\04	\04	\04	\04
SIGTRAP	\05	\05	\05	\05
SIGABRT	\06	\06	\06	\06
SIGIOT	\06	\06	\06	\06
SIGBUS	\07	10	10	10
SIGEMT	\-	\07	\07	\-
SIGFPE	\08	\08	\08	\08
SIGKILL	\09	\09	\09	\09
SIGUSR1	10	30	16	16
SIGSEGV	11	11	11	11
SIGUSR2	12	31	17	17
SIGPIPE	13	13	13	13
SIGALRM	14	14	14	14
SIGTERM	15	15	15	15
SIGSTKFLT	16	\-	\-	\07
SIGCHLD	17	20	18	18
SIGCLD	\-	\-	18	\-
SIGCONT	18	19	25	26
SIGSTOP	19	17	23	24
SIGTSTP	20	18	24	25
SIGTTIN	21	21	26	27
SIGTTOU	22	22	27	28
SIGURG	23	16	21	29
SIGXCPU	24	24	30	12
SIGXFSZ	25	25	31	30
SIGVTALRM	26	26	28	20
SIGPROF	27	27	29	21
SIGWINCH	28	28	20	23
SIGIO	29	23	22	22
SIGPOLL					jak SIGIO
SIGPWR	30	29/\-	19	19
SIGINFO	\-	29/\-	\-	\-
SIGLOST	\-	\-/29	\-	\-
SIGSYS	31	12	12	31
SIGUNUSED	31	\-	\-	31
.TE
.P
Proszę zauważyć, co następuje:
.IP \[bu] 3
Jeśli \fBSIGUNUSED\fP jest zdefiniowany, to jest synonimem dla \fBSIGSYS\fP. Od
glibc 2.26, \fBSIGUNUSED\fP nie jest już zdefiniowany na żadnej architekturze.
.IP \[bu]
.\"
Sygnał 29 oznacza \fBSIGINFO\fP/\fBSIGPWR\fP (synonimy o tej samej wartości) na
architekturze Alpha, lecz \fBSIGLOST\fP na architekturze SPARC.
.SS "Sygnały czasu rzeczywistego"
Od Linuksa 2.2, Linux wspiera sygnały czasu rzeczywistego zdefiniowane
pierwotnie w rozszerzeniu dla czasu rzeczywistego POSIX.1b (a obecnie
zawarte w POSIX.1\-2001). Zakres obsługiwanych sygnałów czasu rzeczywistego
jest definiowany przez makra \fBSIGRTMIN\fP i  \fBSIGRTMAX\fP. POSIX.1\-2001 wymaga
od implementacji wspierania co najmniej \fB_POSIX_RTSIG_MAX\fP (8) sygnałów
czasu rzeczywistego.
.P
Jądro Linux wspiera 33 różne sygnały czasu rzeczywistego, o numerach od 32
do 64. Jednakże implementacja wątków POSIX w glibc używa dwóch (dla NPTL)
lub trzech (dla LinuxThreads) z nich na swoje wewnętrzne potrzeby (patrz
\fBpthreads\fP(7)), odpowiednio zmieniając także \fBSIGRTMIN\fP (na 34 lub
35). Ponieważ zakres dostępnych sygnałów czasu rzeczywistego zmienia się
zależnie od implementacji wątków w glibc (różnice mogą występować również w
czasie działania aplikacji, zależnie od wersji jądra i glibc) i tak naprawdę
zakres ten różni się pomiędzy implementacjami Uniksa, programy \fInigdy nie powinny się odwoływać do sygnałów czasu rzeczywistego za pomocą liczb wpisanych na stałe\fP, ale powinny zawsze się odwoływać do sygnałów czasu
rzeczywistego używając notacji \fBSIGRTMIN\fP+n, i sprawdzać (podczas działania
aplikacji), czy \fBSIGRTMIN\fP+n nie przekracza \fBSIGRTMAX\fP.
.P
W odróżnieniu od sygnałów standardowych, sygnały czasu rzeczywistego nie
mają predefiniowanego znaczenia: można wykorzystywać cały zestaw sygnałów
czasu rzeczywistego do celów określonych w aplikacji.
.P
Domyślną akcją na nieobsłużony sygnał czasu rzeczywistego jest przerwanie
procesu, który go otrzymał.
.P
Sygnały czasu rzeczywistego są rozpoznawane w następujący sposób:
.IP \[bu] 3
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.
.IP \[bu]
Jeśli sygnał wysłano korzystając z \fBsigqueue\fP(3), 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
\fBSA_SIGACTION\fP funkcji \fBsigaction\fP(2), to otrzymuje towarzyszącą mu daną
za pośrednictwem pola \fIsi_value\fP struktury \fIsiginfo_t\fP przekazanej jako
drugi argument funkcji obsługi. Ponadto, pola \fIsi_pid\fP oraz \fIsi_uid\fP tej
struktury mogą służyć do otrzymania identyfikatora procesu oraz
rzeczywistego identyfikatora użytkownika procesu wysyłającego sygnał.
.IP \[bu]
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). Sygnały standardowe zachowują się inaczej: jeśli kilka
standardowych sygnałów oczekuje na proces, to kolejność dostarczenia nie
jest określona.
.P
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.
.P
Zgodnie z POSIX, implementacja powinna zezwalać na kolejkowanie do procesu
co najmniej \fB_POSIX_SIGQUEUE_MAX\fP (32) sygnałów czasu
rzeczywistego. Jednakże w Linuksie zostało to zaimplementowane inaczej. Aż
do Linuksa 2.6.7 (włącznie), Linux narzuca ogólnosystemowe ograniczenie
liczby sygnałów czasu rzeczywistego kolejkowanych do wszystkich
procesów. Ograniczenie to można zobaczyć, a także (przy odpowiednich
uprawnieniach) zmienić za pośrednictwem pliku
\fI/proc/sys/kernel/rtsig\-max\fP. Podobnie, za pośrednictwem pliku
\fI/proc/sys/kernel/rtsig\-nr\fP można dowiedzieć się, ile sygnałów czasu
rzeczywistego jest aktualnie w kolejce. W Linuksie 2.6.8 ten interfejs
\fI/proc\fP został zastąpiony limitem zasobów \fBRLIMIT_SIGPENDING\fP, który
określa limit kolejkowanych sygnałów dla poszczególnych użytkowników; patrz
\fBsetrlimit\fP(2) w celu uzyskania dalszych informacji.
.P
Dodanie sygnałów czasu rzeczywistego wymogło poszerzenie struktury zestawu
sygnałów (\fIsigset_t\fP) z 32 do 64 bitów. W konsekwencji różne wywołania
systemowe zostały zastąpione nowymi, które obsługują większy zestaw
sygnałów. Oto stare i nowe wywołania systemowe:
.TS
lb lb
l l.
Linux 2.0 i wcześniejsze	Linux 2.2 i późniejsze
\fBsigaction\fP(2)	\fBrt_sigaction\fP(2)
\fBsigpending\fP(2)	\fBrt_sigpending\fP(2)
\fBsigprocmask\fP(2)	\fBrt_sigprocmask\fP(2)
\fBsigreturn\fP(2)	\fBrt_sigreturn\fP(2)
\fBsigsuspend\fP(2)	\fBrt_sigsuspend\fP(2)
\fBsigtimedwait\fP(2)	\fBrt_sigtimedwait\fP(2)
.TE
.\"
.SS "Przerywanie wywołań systemowych i funkcji bibliotecznych przez funkcje obsługi sygnałów"
Jeśli procedura obsługi sygnału jest wywołana w trakcie wywołania
systemowego lub wywołania funkcji bibliotecznej to wtedy albo:
.IP \[bu] 3
wywołanie jest automatycznie uruchamiane ponownie po zakończeniu funkcji
obsługującej sygnał, albo
.IP \[bu]
wywołanie zwraca błąd \fBEINTR\fP.
.P
To, które z powyższych wystąpi, zależy od interfejsu i od tego, czy podczas
ustanawiania funkcji obsługi sygnału użyto znacznika  \fBSA_RESTART\fP (patrz
\fBsigaction\fP(2)). Szczegóły się różnią między różnymi Uniksami, poniżej
podano szczegóły dotyczące Linuksa.
.P
.\" The following system calls use ERESTARTSYS,
.\" so that they are restartable
Jeśli blokowane wywołanie jednego z poniższych interfejsów zostanie
przerwane przez procedurę obsługi sygnału, to wywołanie to zostanie
automatycznie uruchomione ponownie, jeśli użyto znacznika \fBSA_RESTART\fP. W
przeciwnym wypadku wywołanie zwróci błąd \fBEINTR\fP:
.IP \[bu] 3
Wywołania \fBread\fP(2), \fBreadv\fP(2), \fBwrite\fP(2), \fBwritev\fP(2) i \fBioctl\fP(2)
na urządzeniach \[Bq]powolnych\[rq]. Urządzenie \[Bq]powolne\[rq] to takie,
w którym operacja wejścia/wyjścia może się blokować przez nieskończony czas,
na przykład: terminal, potok lub gniazdo. Jeśli wywołanie systemowe
wejścia/wyjścia na urządzeniu powolnym spowodowało już jakiś transfer
danych, zanim zostało przerwane przez sygnał, to zwróci ono pomyślny kod
zakończenie (będący zazwyczaj liczbą przetransferowanych bajtów). Proszę
zauważyć, że (lokalny) dysk zgodnie z tą definicją nie jest urządzeniem
powolnym: operacje wejścia/wyjścia na urządzeniach dyskowych nie są
przerywane sygnałami.
.IP \[bu]
\fBopen\fP(2), jeśli może się zablokować (np. podczas otwierania FIFO, patrz
\fBfifo\fP(7)).
.IP \[bu]
\fBwait\fP(2), \fBwait3\fP(2), \fBwait4\fP(2), \fBwaitid\fP(2) i \fBwaitpid\fP(2).
.IP \[bu]
.\" If a timeout (setsockopt()) is in effect on the socket, then these
.\" system calls switch to using EINTR.  Consequently, they and are not
.\" automatically restarted, and they show the stop/cont behavior
.\" described below.  (Verified from Linux 2.6.26 source, and by experiment; mtk)
.\" FIXME What about sendmmsg()?
Interfejsy gniazd: \fBaccept\fP(2), \fBconnect\fP(2), \fBrecv\fP(2), \fBrecvfrom\fP(2),
\fBrecvmmsg\fP(2), \fBrecvmsg\fP(2), \fBsend\fP(2), \fBsendto\fP(2) i \fBsendmsg\fP(2),
chyba że ustawiono czas przeterminowania na gnieździe (patrz niżej).
.IP \[bu]
Interfejsy blokady plików: \fBflock\fP(2) i \fBF_SETLKW\fP oraz operacje
\fBF_OFD_SETLKW\fP \fBfcntl\fP(2)
.IP \[bu]
Interfejsy kolejek komunikatów POSIX: \fBmq_receive\fP(3),
\fBmq_timedreceive\fP(3), \fBmq_send\fP(3) i \fBmq_timedsend\fP(3).
.IP \[bu]
.\" commit 72c1bbf308c75a136803d2d76d0e18258be14c7a
\fBfutex\fP(2) \fBFUTEX_WAIT\fP (od Linuksa 2.6.22; wcześniej zawsze zwracał błąd
\fBEINTR\fP).
.IP \[bu]
\fBgetrandom\fP(2).
.IP \[bu]
\fBpthread_mutex_lock\fP(3), \fBpthread_cond_wait\fP(3) i powiązane API.
.IP \[bu]
\fBfutex\fP(2)  \fBFUTEX_WAIT_BITSET\fP.
.IP \[bu]
.\" as a consequence of the 2.6.22 changes in the futex() implementation
Interfejsy semaforów POSIX: \fBsem_wait\fP(3) i \fBsem_timedwait\fP(3) (od Linuksa
2.6.22;  wcześniejsze wersje zawsze zwracały błąd \fBEINTR\fP).
.IP \[bu]
.\" commit 1ca39ab9d21ac93f94b9e3eb364ea9a5cf2aba06
\fBread\fP(2) z deskryptora pliku \fBinotify\fP(7) (od Linuksa 3.8; wcześniej
zawsze zwracało błąd \fBEINTR\fP).
.P
.\" These are the system calls that give EINTR or ERESTARTNOHAND
.\" on interruption by a signal handler.
Następujące interfejsy nigdy nie są wznawiane po przerwaniu przez funkcję
obsługi sygnału, niezależnie od tego, czy \fBSA_RESTART\fP zostało użyte. Jeśli
zostaną przerwane przez funkcję obsługi sygnału, to zawsze kończą się
niepowodzeniem, zwracając błąd \fBEINTR\fP:
.IP \[bu] 3
\[Bq]Wejściowe\[rq] interfejsy gniazd, jeśli ustawiono czas przeterminowania
gniazda (\fBSO_RCVTIMEO\fP) za pomocą \fBsetsockopt\fP(2): \fBaccept\fP(2),
\fBrecv\fP(2), \fBrecvfrom\fP(2), \fBrecvmmsg\fP(2)  (również z niezerowym argumentem
\fItimeout\fP) i \fBrecvmsg\fP(2).
.IP \[bu]
.\" FIXME What about sendmmsg()?
\[Bq]Wyjściowe\[rq] interfejsy gniazd, jeśli ustawiono czas przeterminowania
gniazda (\fBSO_RCVTIMEO\fP) za pomocą \fBsetsockopt\fP(2): \fBconnect\fP(2),
\fBsend\fP(2), \fBsendto\fP(2) i \fBsendmsg\fP(2).
.IP \[bu]
Interfejsy oczekiwania na sygnały: \fBpause\fP(2), \fBsigsuspend\fP(2),
\fBsigtimedwait\fP(2) i \fBsigwaitinfo\fP(2).
.IP \[bu]
Interfejsy zwielokrotniające deskryptory plików: \fBepoll_wait\fP(2),
\fBepoll_pwait\fP(2), \fBpoll\fP(2), \fBppoll\fP(2), \fBselect\fP(2) i \fBpselect\fP(2).
.IP \[bu]
.\" On some other systems, SA_RESTART does restart these system calls
Interfejsy komunikacji międzyprocesowej Systemu V: \fBmsgrcv\fP(2),
\fBmsgsnd\fP(2), \fBsemop\fP(2) oraz \fBsemtimedop\fP(2).
.IP \[bu]
Interfejsy pauzujące proces: \fBclock_nanosleep\fP(2), \fBnanosleep\fP(2) i
\fBusleep\fP(3).
.IP \[bu]
\fBio_getevents\fP(2).
.P
Funkcja \fBsleep\fP(3) nigdy nie zostanie zrestartowana po przerwaniu przez
sygnał i zawsze kończy się pomyślnie, zwracając liczbę pozostałych sekund,
podczas których proces powinien był pauzować.
.P
.\"
W pewnych okolicznościach, funkcji powiadomień w przestrzeni użytkownika
\fBseccomp\fP(2), może spowodować ponowne uruchomienia wywołań systemowych,
które w innych przypadkach nigdy nie zostałyby zrestartowane przez
\fBSA_RESTART\fP; więcej szczegółów w podręczniku \fBseccomp_unotify\fP(2).
.SS "Przerywanie wywołań systemowych i funkcji bibliotecznych przez sygnały zatrzymujące proces"
Pod Linuksem, nawet jeśli procedury obsługi sygnału nie zostaną ustawione,
pewne interfejsy blokujące mogą się zakończyć niepowodzeniem i zwrócić błąd
\fBEINTR\fP po tym, jak proces zostanie zatrzymany za pomocą jednego z sygnałów
zatrzymujących (takich jak \fBSIGSTOP\fP), a następnie wznowiony za pomocą
\fBSIGCONT\fP. POSIX.1 nie wspiera tego zachowania, nie występuje ono także na
innych systemach.
.P
Następujące interfejsy Linuksa zachowują się w ten sposób:
.IP \[bu] 3
\[Bq]Wejściowe\[rq] interfejsy gniazd, jeśli ustawiono czas przeterminowania
gniazda (\fBSO_RCVTIMEO\fP) za pomocą \fBsetsockopt\fP(2): \fBaccept\fP(2),
\fBrecv\fP(2), \fBrecvfrom\fP(2), \fBrecvmmsg\fP(2)  (również z niezerowym argumentem
\fItimeout\fP) i \fBrecvmsg\fP(2).
.IP \[bu]
.\" FIXME What about sendmmsg()?
\[Bq]Wyjściowe\[rq] interfejsy gniazd, jeśli ustawiono czas przeterminowania
gniazda (\fBSO_RCVTIMEO\fP) za pomocą \fBsetsockopt\fP(2): \fBconnect\fP(2),
\fBsend\fP(2), \fBsendto\fP(2) i \fBsendmsg\fP(2), jeśli ustawiono czas
przeterminowania wysyłania danych(\fBSO_SNDTIMEO\fP).
.IP \[bu]
\fBepoll_wait\fP(2), \fBepoll_pwait\fP(2).
.IP \[bu]
\fBsemop\fP(2), \fBsemtimedop\fP(2).
.IP \[bu]
\fBsigtimedwait\fP(2), \fBsigwaitinfo\fP(2).
.IP \[bu]
.\" commit 1ca39ab9d21ac93f94b9e3eb364ea9a5cf2aba06
Linux 3.7 i wcześniejsze: \fBread\fP(2) czytające z deskryptora pliku
\fBinotify\fP(7).
.IP \[bu]
Linux 2.6.21 i wcześniejsze: \fBfutex\fP(2)  \fBFUTEX_WAIT\fP,
\fBsem_timedwait\fP(3), \fBsem_wait\fP(3).
.IP \[bu]
Linux 2.6.8 i wcześniejsze: \fBmsgrcv\fP(2), \fBmsgsnd\fP(2).
.IP \[bu]
Linux 2.4 i wcześniejsze: \fBnanosleep\fP(2).
.SH STANDARDY
POSIX.1, z wyjątkami jak podano.
.SH UWAGI
Opis funkcji async\-signal\-safe znajduje się w podręczniku
\fBsignal\-safety\fP(7).
.P
Plik \fI/proc/\fPpid\fI/task/\fPtid\fI/status\fP zawiera różne pola, które pokazują
sygnały, które sygnał: blokuje (\fISigBlk\fP), przechwytuje (\fISigCgt\fP) lub
ignoruje (\fISigIgn\fP) (przy czym zbiór sygnałów przechwytywanych lub
ignorowanych jest taki sam dla wszystkich wątków procesu). Inne pola ukazują
zbiór sygnałów oczekujących, które są skierowane do wątku (\fISigPnd\fP) oraz
zbiór sygnałów oczekujących, które są skierowane do całego procesu
(\fIShdPnd\fP). Odpowiadające im pola w \fI/proc/\fPpid\fI/status\fP pokazują
informacje dla głównego wątku. Więcej szczegółów w podręczniku \fBproc\fP(5).
.SH USTERKI
Istnieje sześć sygnałów, które mogą być dostarczone z powodu wyjątku
sprzętowego: \fBSIGBUS\fP, \fBSIGEMT\fP, \fBSIGFPE\fP, \fBSIGILL\fP, \fBSIGSEGV\fP i
\fBSIGTRAP\fP. To, które z nich są dostarczane dla jakiegoś wyjątku sprzętowego
nie jest udokumentowane i nie zawsze ma sens.
.P
Przykładowo, nieprawidłowy dostęp do pamięci, który powoduje dostarczenie
sygnału \fBSIGSEGV\fP na jednej architekturze procesora, może powodować
dostarczanie sygnału \fBSIGBUS\fP na innej architekturze lub odwrotnie.
.P
Innym przykładem jest instrukcja \fIint\fP x86 z zabronionym argumentem (liczbą
inną niż 3 lub 128), która powoduje dostarczenie \fBSIGSEGV\fP, choć
logiczniejszy, z powodu sposobu, w jaki procesor informuje jądro o
zabronionych operacjach, byłby sygnał \fBSIGILL\fP.
.SH "ZOBACZ TAKŻE"
\fBkill\fP(1), \fBclone\fP(2), \fBgetrlimit\fP(2), \fBkill\fP(2),
\fBpidfd_send_signal\fP(2), \fBrestart_syscall\fP(2), \fBrt_sigqueueinfo\fP(2),
\fBsetitimer\fP(2), \fBsetrlimit\fP(2), \fBsgetmask\fP(2), \fBsigaction\fP(2),
\fBsigaltstack\fP(2), \fBsignal\fP(2), \fBsignalfd\fP(2), \fBsigpending\fP(2),
\fBsigprocmask\fP(2), \fBsigreturn\fP(2), \fBsigsuspend\fP(2), \fBsigwaitinfo\fP(2),
\fBabort\fP(3), \fBbsd_signal\fP(3), \fBkillpg\fP(3), \fBlongjmp\fP(3),
\fBpthread_sigqueue\fP(3), \fBraise\fP(3), \fBsigqueue\fP(3), \fBsigset\fP(3),
\fBsigsetops\fP(3), \fBsigvec\fP(3), \fBsigwait\fP(3), \fBstrsignal\fP(3),
\fBswapcontext\fP(3), \fBsysv_signal\fP(3), \fBcore\fP(5), \fBproc\fP(5), \fBnptl\fP(7),
\fBpthreads\fP(7), \fBsigevent\fP(3type)
.PP
.SH TŁUMACZENIE
Autorami polskiego tłumaczenia niniejszej strony podręcznika są:
Przemek Borys <pborys@dione.ids.pl>,
Robert Luberda <robert@debian.org>
i
Michał Kułach <michal.kulach@gmail.com>
.
.PP
Niniejsze tłumaczenie jest wolną dokumentacją. Bliższe informacje o warunkach
licencji można uzyskać zapoznając się z
.UR https://www.gnu.org/licenses/gpl-3.0.html
GNU General Public License w wersji 3
.UE
lub nowszej. Nie przyjmuje się ŻADNEJ ODPOWIEDZIALNOŚCI.
.PP
Błędy w tłumaczeniu strony podręcznika prosimy zgłaszać na adres listy
dyskusyjnej
.MT manpages-pl-list@lists.sourceforge.net
.ME .
