.\" -*- coding: UTF-8 -*- '\" t .\" Copyright (c) 1993 by Thomas Koenig (ig25@rz.uni-karlsruhe.de) .\" and Copyright (c) 2002, 2006, 2020 by Michael Kerrisk .\" and Copyright (c) 2008 Linux Foundation, written by Michael Kerrisk .\" .\" .\" 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 .\" Modified 7 Jun 2002, by Michael Kerrisk .\" Added information on real-time signals .\" Modified 13 Jun 2002, by Michael Kerrisk .\" 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 "17 czerwca 2024 r." "Linux man\-pages 6.9.1" .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). Obiekt ten wskazuje na stan, w jakim dostarczono sygnał, zamiast na procedurę obsługę; np. maska zablokowanych sygnałów przechowana w tym obiekcie nie będzie zawierała maski nowych sygnałów blokowanych za pomocą \fBsigaction\fP(2). .IP (1.4) Wszelkie sygnały podane w \fIact\->sa_mask\fP przy rejestracji procedury obsługi przy użyciu \fBsigaction\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 Tłumaczenie niniejszej strony podręcznika: Przemek Borys , Robert Luberda i Michał Kułach . .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 .