plucky (7) signal.7.gz

Provided by: manpages-pl_4.25.1-1_all bug

NAZWA

       signal - przegląd 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”  tabel  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 signal(2) (to drugie jest mniej
       przenośne, jeśli chodzi o ustawianie akcji obsługi sygnału; szczegóły opisano w 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 procedurę obsługi sygnału, czyli podaną przez
       programistę funkcję, wywoływaną automatycznie po dostarczeniu sygnału.

       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 sigaltstack(2)

       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.

       Potomek  utworzony przez fork(2) dziedziczy kopię ustawień sygnałów od swojego rodzica. Podczas wywołania
       execve(2) przywracane są wartości domyślne ustawień, z wyjątkiem ustawienia  ignorowania  sygnału,  które
       nie jest zmieniane.

   Wysyłanie sygnału
       Następujące wywołania systemowe lub funkcje biblioteczne umożliwiają wysyłanie sygnałów:

       raise(3)
              Wysyła sygnał do wątku, który wywołał tę funckję.

       kill(2)
              Wysyła  sygnał  do  podanego  procesu  lub  do  wszystich  członków podanej grupy procesów, lub do
              wszystkich procesów w systemie.

       pidfd_send_signal(2)
              Wysyła sygnał do procesu identyfikowanego za pomocą deskryptora pliku PID.

       killpg(3)
              Wysyła sygnał do wszystkich członków podanej grupy procesów.

       pthread_kill(3)
              Wysyła sygnał do podanego wątku POSIX w tym samym procesie, co proces wywołujący.

       tgkill(2)
              Wysyła sygnał do  podanego  wątku  w  podanym  procesie  (jest  to  używane  do  zaimplementowania
              pthread_kill(3)).

       sigqueue(3)
              Wysyła sygnał czasu rzeczywistego wraz z powiązanymi danymi do podanego procesu.

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

       pause(2)
              Zawiesza wykonywanie do momentu złapania sygnału.

       sigsuspend(2)
              Tymczasowo zmienia maskę sygnału (patrz niżej) i zawiesza  wykonywanie  do  momentu  przechwycenia
              jednego z niemaskowanych sygnałów.

   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:

       •  sigwaitinfo(2), sigtimedwait(2) oraz sigwait(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.

       •  signalfd(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ą  read(2)  z  tego  deskryptora
          pliku  jest blokowana do czasu dostarczenia do programu wywołującego jednego z sygnałów przekazanych w
          zbiorze signalfd(2). Bufor zwracany przez read(2) zawiera strukturę opisującą sygnał.

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

       Dziecko  utworzone  przez  fork(2)  dziedziczy  kopię  maski  sygnałów  od  swojego  rodzica.  Maska jest
       zachowywana podczas wywołań execve(2).

       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ą  kill(2) lub sigqueue(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. SIGSEGV w przypadku nieprawidłowego dostępu do
       pamięci lub SIGFPE w przypadku błędu matematycznego) albo ponieważ jest kierowany  do  konkretnego  wątku
       poprzez interfejs taki jak tgkill(2) lub pthread_kill(3).

       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.

       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.

       Zbiór sygnałów oczekujących dziecka utworzonego przez fork(2) jest na samym  początku  pusty.  Zbiór  ten
       jest zachowywany podczas execve(2).

   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:

       (1)  Jądro przeprowadza niezbędne działania przygotowawcze do wykonania procedury obsługi sygnału:

            (1.1)  Sygnał jest usuwany ze zbioru oczekujących sygnałów.

            (1.2)  Jeśli sygnał został zainstalowany wywołaniem do sigaction(2) ze znacznikiem  SA_ONSTACK  oraz
                   wątek  zdefiniował  alternatywny  stos  sygnałów  (za  pomocą sigaltstack(2)) — stos ten jest
                   instalowany.

            (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ą:

                   •  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);

                   •  Stan rejestru zależny od architektury, wymagany do wznowienia przerwanego programu;

                   •  bieżąca maska sygnałów wątku;

                   •  ustawienia alternatywnego stosu sygnałów wątku.

                   If the signal handler was installed using the sigaction(2)  SA_SIGINFO flag, then  the  above
                   information  is accessible via the ucontext_t object that is pointed to by the third argument
                   of the signal handler.  This object reflects the state at  which  the  signal  is  delivered,
                   rather  than  in  the handler; for example, the mask of blocked signals stored in this object
                   will not contain the mask of new signals blocked through sigaction(2).

            (1.4)  Any signals specified in act->sa_mask when registering the  handler  with  sigaction(2)   are
                   added  to  the  thread's signal mask.  The signal being delivered is also added to the signal
                   mask, unless SA_NODEFER was specified when registering the handler.  These signals  are  thus
                   blocked while the handler executes.

       (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 sigreturn(2)).

       (3)  Jądro zwraca kontrolę do przestrzeni użytkownika, gdzie wykonanie zaczyna się  na  początku  funkcji
            obsługi sygnału.

       (4)  Gdy procedura obsługi sygnału powróci, kontrola jest przekazywana do kodu trampoliny sygnału.

       (5)  Trampolina  sygnału  wywołuje  sigreturn(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 sigreturn(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.

       Proszę  zauważyć,  że  jeśli procedura obsługi sygnału nie powróci (np. kontrola zostanie przekazana poza
       procedurę obsługi  za  pomocą  siglongjmp(3)  albo  procedura  obsługi  wykona  nowy  program  za  pomocą
       execve(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  sigprocmask(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 siglongjmp(3) może, ale nie musi przywrócić maski sygnałów, w zależności  od
       wartości savesigs podanej w odpowiednim wywołaniu do sigsetjmp(3)).

       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!).

   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ł:  „P1990”  oznacza,  że sygnał był opisany w pierwotnym standardzie POSIX.1-1990; „P2001”
       wskazuje, że sygnał dodano w SUSv2 i POSIX.1-2001.

       Sygnał      Standard   Akcja   Komentarz
       ─────────────────────────────────────────────────────────────────────────
       SIGABRT      P1990     Core    Sygnał abort od abort(3)
       SIGALRM      P1990     Term    Sygnał timera od alarm(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 SIGCHLD
       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 SIGPWR
       SIGINT       P1990     Term    Przerwanie nakazane z klawiatury
       SIGIO          -       Term    I/O teraz możliwe (4.2BSD)
       SIGIOT         -       Core    Pułapka IOT. Synonim SIGABRT
       SIGKILL      P1990     Term    Sygnał Kill
       SIGLOST        -       Term    Utracono blokadę pliku (nieużywane)
       SIGPIPE      P1990     Term    Uszkodzony potok: zapis do potoku bez
                                      odczytujących; zob. pipe(7)
       SIGPOLL      P2001     Term    Zdarzenie odpytywalne (Sys V);
                                      synonim dla SIGIO
       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ż seccomp(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 SIGSYS
       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. setrlimit(2)
       SIGXFSZ      P2001     Core    Przekr. ogran. rozmiaru pliku (4.2BSD)
                                      zob. setrlimit(2)
       SIGWINCH       -        Ign    Sygnał zmiany rozm. okna (4.3BSD, Sun)

       Sygnałów SIGKILL oraz SIGSTOP nie można przechwycić, zablokować ani zignorować.

       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.1-2001 dotyczącymi tych sygnałów i
       przerywa proces ze zrzutem pamięci.

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

       SIGPWR  (niewymieniony  w  POSIX.1-2001)  jest  zazwyczaj domyślnie ignorowany w tych Uniksach, w których
       występuje.

       SIGIO (niewymieniony w POSIX.1-2001) jest domyślnie ignorowany w niektórych innych Uniksach.

   Kolejkowanie i semantyka dostarczania sygnałów standardowych
       Jeśli na proces oczekuje kilka sygnałów standardowych, kolejność,  w  jakiej  zostaną  dostarczone,  jest
       nieokreślona.

       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 siginfo_t (zob. sigaction(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.

   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 — MIPS; a ostatnia — PARISC. Kreska (-) wskazuje, że sygnał nie
       występuje na danej architekturze.

       Sygnał          x86/ARM        Alpha/   MIPS   PARISC   Uwagi
                   większość innych   SPARC
       ──────────────────────────────────────────────────────────────────
       SIGHUP              1             1       1       1
       SIGINT              2             2       2       2
       SIGQUIT             3             3       3       3
       SIGILL              4             4       4       4
       SIGTRAP             5             5       5       5
       SIGABRT             6             6       6       6
       SIGIOT              6             6       6       6
       SIGBUS              7            10      10      10
       SIGEMT             -              7       7      -
       SIGFPE              8             8       8       8
       SIGKILL             9             9       9       9
       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            -       -        7
       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

       Proszę zauważyć, co następuje:

       •  Jeśli SIGUNUSED jest zdefiniowany, to jest synonimem dla SIGSYS. Od glibc 2.26, SIGUNUSED nie jest już
          zdefiniowany na żadnej architekturze.

       •  Sygnał  29 oznacza SIGINFO/SIGPWR (synonimy o tej samej wartości) na architekturze Alpha, lecz SIGLOST
          na architekturze SPARC.

   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 SIGRTMIN i  SIGRTMAX.  POSIX.1-2001  wymaga  od  implementacji
       wspierania co najmniej _POSIX_RTSIG_MAX (8) sygnałów czasu rzeczywistego.

       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  pthreads(7)),  odpowiednio  zmieniając  także  SIGRTMIN (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  nigdy  nie  powinny  się  odwoływać  do
       sygnałów  czasu  rzeczywistego  za  pomocą  liczb wpisanych na stałe, ale powinny zawsze się odwoływać do
       sygnałów czasu rzeczywistego używając notacji SIGRTMIN+n, i sprawdzać (podczas działania aplikacji),  czy
       SIGRTMIN+n nie przekracza SIGRTMAX.

       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.

       Domyślną 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:

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

       •  Jeśli sygnał wysłano korzystając z sigqueue(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 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 identyfikatora procesu  oraz  rzeczywistego
          identyfikatora użytkownika procesu wysyłającego sygnał.

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

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

       Dodanie sygnałów czasu rzeczywistego wymogło poszerzenie struktury zestawu sygnałów (sigset_t) 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:

       Linux 2.0 i wcześniejsze   Linux 2.2 i późniejsze
       sigaction(2)               rt_sigaction(2)
       sigpending(2)              rt_sigpending(2)
       sigprocmask(2)             rt_sigprocmask(2)
       sigreturn(2)               rt_sigreturn(2)
       sigsuspend(2)              rt_sigsuspend(2)
       sigtimedwait(2)            rt_sigtimedwait(2)

   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:

       •  wywołanie jest automatycznie uruchamiane ponownie po zakończeniu funkcji obsługującej sygnał, albo

       •  wywołanie zwraca błąd EINTR.

       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  SA_RESTART (patrz sigaction(2)). Szczegóły się różnią między  różnymi  Uniksami,
       poniżej podano szczegóły dotyczące Linuksa.

       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 SA_RESTART. W
       przeciwnym wypadku wywołanie zwróci błąd EINTR:

       •  Wywołania  read(2),  readv(2),  write(2), writev(2) i ioctl(2) na urządzeniach „powolnych”. Urządzenie
          „powolne” 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.

       •  open(2), jeśli może się zablokować (np. podczas otwierania FIFO, patrz fifo(7)).

       •  wait(2), wait3(2), wait4(2), waitid(2) i waitpid(2).

       •  Interfejsy  gniazd:  accept(2),  connect(2),  recv(2),  recvfrom(2), recvmmsg(2), recvmsg(2), send(2),
          sendto(2) i sendmsg(2), chyba że ustawiono czas przeterminowania na gnieździe (patrz niżej).

       •  Interfejsy blokady plików: flock(2) i F_SETLKW oraz operacje F_OFD_SETLKW fcntl(2)

       •  Interfejsy kolejek komunikatów POSIX: mq_receive(3), mq_timedreceive(3), mq_send(3) i mq_timedsend(3).

       •  futex(2) FUTEX_WAIT (od Linuksa 2.6.22; wcześniej zawsze zwracał błąd EINTR).

       •  getrandom(2).

       •  pthread_mutex_lock(3), pthread_cond_wait(3) i powiązane API.

       •  futex(2)  FUTEX_WAIT_BITSET.

       •  Interfejsy semaforów POSIX: sem_wait(3) i sem_timedwait(3) (od Linuksa  2.6.22;   wcześniejsze  wersje
          zawsze zwracały błąd EINTR).

       •  read(2) z deskryptora pliku inotify(7) (od Linuksa 3.8; wcześniej zawsze zwracało błąd EINTR).

       Następujące interfejsy nigdy nie są wznawiane po przerwaniu przez funkcję obsługi sygnału, niezależnie od
       tego, czy SA_RESTART zostało użyte. Jeśli zostaną przerwane przez  funkcję  obsługi  sygnału,  to  zawsze
       kończą się niepowodzeniem, zwracając błąd EINTR:

       •  „Wejściowe”  interfejsy  gniazd, jeśli ustawiono czas przeterminowania gniazda (SO_RCVTIMEO) za pomocą
          setsockopt(2): accept(2), recv(2), recvfrom(2), recvmmsg(2)  (również z niezerowym argumentem timeout)
          i recvmsg(2).

       •  „Wyjściowe”  interfejsy  gniazd, jeśli ustawiono czas przeterminowania gniazda (SO_RCVTIMEO) za pomocą
          setsockopt(2): connect(2), send(2), sendto(2) i sendmsg(2).

       •  Interfejsy oczekiwania na sygnały: pause(2), sigsuspend(2), sigtimedwait(2) i sigwaitinfo(2).

       •  Interfejsy zwielokrotniające deskryptory plików:  epoll_wait(2),  epoll_pwait(2),  poll(2),  ppoll(2),
          select(2) i pselect(2).

       •  Interfejsy komunikacji międzyprocesowej Systemu V: msgrcv(2), msgsnd(2), semop(2) oraz semtimedop(2).

       •  Interfejsy pauzujące proces: clock_nanosleep(2), nanosleep(2) i usleep(3).

       •  io_getevents(2).

       Funkcja  sleep(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ć.

       W pewnych okolicznościach, funkcji powiadomień w  przestrzeni  użytkownika  seccomp(2),  może  spowodować
       ponowne  uruchomienia  wywołań  systemowych, które w innych przypadkach nigdy nie zostałyby zrestartowane
       przez SA_RESTART; więcej szczegółów w podręczniku seccomp_unotify(2).

   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 EINTR po tym, jak proces zostanie zatrzymany za pomocą
       jednego z sygnałów zatrzymujących (takich jak SIGSTOP), a następnie wznowiony za pomocą SIGCONT.  POSIX.1
       nie wspiera tego zachowania, nie występuje ono także na innych systemach.

       Następujące interfejsy Linuksa zachowują się w ten sposób:

       •  „Wejściowe”  interfejsy  gniazd, jeśli ustawiono czas przeterminowania gniazda (SO_RCVTIMEO) za pomocą
          setsockopt(2): accept(2), recv(2), recvfrom(2), recvmmsg(2)  (również z niezerowym argumentem timeout)
          i recvmsg(2).

       •  „Wyjściowe”  interfejsy  gniazd, jeśli ustawiono czas przeterminowania gniazda (SO_RCVTIMEO) za pomocą
          setsockopt(2): connect(2), send(2), sendto(2) i  sendmsg(2),  jeśli  ustawiono  czas  przeterminowania
          wysyłania danych(SO_SNDTIMEO).

       •  epoll_wait(2), epoll_pwait(2).

       •  semop(2), semtimedop(2).

       •  sigtimedwait(2), sigwaitinfo(2).

       •  Linux 3.7 i wcześniejsze: read(2) czytające z deskryptora pliku inotify(7).

       •  Linux 2.6.21 i wcześniejsze: futex(2)  FUTEX_WAIT, sem_timedwait(3), sem_wait(3).

       •  Linux 2.6.8 i wcześniejsze: msgrcv(2), msgsnd(2).

       •  Linux 2.4 i wcześniejsze: nanosleep(2).

STANDARDY

       POSIX.1, z wyjątkami jak podano.

UWAGI

       Opis funkcji async-signal-safe znajduje się w podręczniku signal-safety(7).

       Plik  /proc/pid/task/tid/status  zawiera  różne  pola,  które  pokazują  sygnały,  które  sygnał: blokuje
       (SigBlk), przechwytuje (SigCgt) lub ignoruje (SigIgn) (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 (SigPnd) oraz zbiór sygnałów oczekujących, które  są  skierowane  do  całego
       procesu (ShdPnd). Odpowiadające im pola w /proc/pid/status pokazują informacje dla głównego wątku. Więcej
       szczegółów w podręczniku proc(5).

USTERKI

       Istnieje sześć sygnałów, które mogą być dostarczone z powodu wyjątku sprzętowego: SIGBUS, SIGEMT, SIGFPE,
       SIGILL,  SIGSEGV  i  SIGTRAP.  To,  które z nich są dostarczane dla jakiegoś wyjątku sprzętowego nie jest
       udokumentowane i nie zawsze ma sens.

       Przykładowo, nieprawidłowy dostęp do pamięci, który  powoduje  dostarczenie  sygnału  SIGSEGV  na  jednej
       architekturze procesora, może powodować dostarczanie sygnału SIGBUS na innej architekturze lub odwrotnie.

       Innym  przykładem  jest  instrukcja  int  x86 z zabronionym argumentem (liczbą inną niż 3 lub 128), która
       powoduje dostarczenie SIGSEGV, choć logiczniejszy, z powodu sposobu, w jaki procesor  informuje  jądro  o
       zabronionych operacjach, byłby sygnał SIGILL.

ZOBACZ TAKŻE

       kill(1),  clone(2),  getrlimit(2), kill(2), pidfd_send_signal(2), restart_syscall(2), rt_sigqueueinfo(2),
       setitimer(2),  setrlimit(2),   sgetmask(2),   sigaction(2),   sigaltstack(2),   signal(2),   signalfd(2),
       sigpending(2),  sigprocmask(2),  sigreturn(2),  sigsuspend(2),  sigwaitinfo(2),  abort(3), bsd_signal(3),
       killpg(3), longjmp(3), pthread_sigqueue(3), raise(3), sigqueue(3),  sigset(3),  sigsetops(3),  sigvec(3),
       sigwait(3),   strsignal(3),  swapcontext(3),  sysv_signal(3),  core(5),  proc(5),  nptl(7),  pthreads(7),
       sigevent(3type)

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>

       Niniejsze  tłumaczenie  jest  wolną  dokumentacją.  Bliższe informacje o warunkach licencji można uzyskać
       zapoznając się z GNU General Public License w wersji  3  ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩  lub
       nowszej. Nie przyjmuje się ŻADNEJ ODPOWIEDZIALNOŚCI.

       Błędy  w  tłumaczeniu  strony  podręcznika  prosimy  zgłaszać  na  adres  listy dyskusyjnej ⟨manpages-pl-
       list@lists.sourceforge.net⟩.