Provided by: manpages-pl_4.21.0-2_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ł.

       The  entries in the "Action" column of the table below specify the default disposition for
       each signal, as follows:

       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 akcję obsługi  sygnału,  czyli  podaną  przez  programistę  funkcję,  wywoływaną
       automatycznie po dostarczeniu sygnału.

       By  default,  a  signal handler is invoked on the normal process stack.  It is possible to
       arrange that the signal handler  uses  an  alternate  stack;  see  sigaltstack(2)   for  a
       discussion of how to do this and when it might be useful.

       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.

       Dziecko utworzone 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)
              Sends a signal to a process identified by a PID file descriptor.

       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
       The following system calls suspend execution of the  calling  thread  until  a  signal  is
       caught (or an unhandled signal terminates the process):

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

       A signal may be process-directed or thread-directed.  A  process-directed  signal  is  one
       that  is  targeted  at  (and  thus  pending for)  the process as a whole.  A signal may be
       process-directed because it was generated by the kernel for reasons other than a  hardware
       exception, or because it was sent using kill(2)  or sigqueue(3).  A thread-directed signal
       is one that is targeted at a specific thread.  A signal may be thread-directed because  it
       was  generated  as a consequence of executing a specific machine-language instruction that
       triggered a hardware exception (e.g., SIGSEGV for an invalid memory access, or SIGFPE  for
       a  math  error),  or because it was targeted at a specific thread using interfaces such as
       tgkill(2)  or pthread_kill(3).

       A process-directed signal may be delivered to  any  one  of  the  threads  that  does  not
       currently  have  the  signal  blocked.   If  more  than  one of the threads has the signal
       unblocked, then the kernel chooses an arbitrary thread to which to deliver the signal.

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

   Execution of signal handlers
       Whenever  there  is  a transition from kernel-mode to user-mode execution (e.g., on return
       from a system call or scheduling of a thread onto the  CPU),  the  kernel  checks  whether
       there  is  a  pending  unblocked  signal  for  which  the process has established a signal
       handler.  If there is such a pending signal, the following steps occur:

       (1)  The kernel performs the necessary preparatory  steps  for  execution  of  the  signal
            handler:

            (1.1)  The signal is removed from the set of pending signals.

            (1.2)  If  the signal handler was installed by a call to sigaction(2)  that specified
                   the SA_ONSTACK flag and the thread  has  defined  an  alternate  signal  stack
                   (using sigaltstack(2)), then that stack is installed.

            (1.3)  Various  pieces  of signal-related context are saved into a special frame that
                   is created on the stack.  The saved information includes:

                   •  the program counter register (i.e., the address of the next instruction  in
                      the main program that should be executed when the signal handler returns);

                   •  architecture-specific  register state required for resuming the interrupted
                      program;

                   •  the thread's current signal mask;

                   •  the thread's alternate signal stack settings.

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

            (1.4)  Any signals specified  in  act->sa_mask  when  registering  the  handler  with
                   sigprocmask(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)  The kernel constructs a frame for the signal handler on the stack.  The  kernel  sets
            the  program  counter  for the thread to point to the first instruction of the signal
            handler function, and configures the return address for that function to point  to  a
            piece of user-space code known as the signal trampoline (described in sigreturn(2)).

       (3)  The  kernel passes control back to user-space, where execution commences at the start
            of the signal handler function.

       (4)  When the signal handler returns, control passes to the signal trampoline code.

       (5)  The signal trampoline calls sigreturn(2), a system call that uses the information  in
            the  stack  frame  created  in  step  1 to restore the thread to its state before the
            signal handler was called.  The thread's  signal  mask  and  alternate  signal  stack
            settings  are  restored  as  part  of this procedure.  Upon completion of the call to
            sigreturn(2), the kernel transfers  control  back  to  user  space,  and  the  thread
            recommences execution at the point where it was interrupted by the signal handler.

       Note  that  if the signal handler does not return (e.g., control is transferred out of the
       handler using siglongjmp(3), or the handler executes a new program with  execve(2)),  then
       the  final step is not performed.  In particular, in such scenarios it is the programmer's
       responsibility to restore the state of the signal mask (using sigprocmask(2)),  if  it  is
       desired  to  unblock  the signals that were blocked on entry to the signal handler.  (Note
       that siglongjmp(3)  may or may not restore the signal  mask,  depending  on  the  savesigs
       value that was specified in the corresponding call to sigsetjmp(3).)

       From  the kernel's point of view, execution of the signal handler code is exactly the same
       as the execution of any other user-space code.  That is to say, the kernel does not record
       any  special  state information indicating that the thread is currently executing inside a
       signal handler.  All necessary state information is maintained in user-space registers and
       the  user-space  stack.   The depth to which nested signal handlers may be invoked is thus
       limited only by the user-space stack (and sensible software design!).

   Sygnały standardowe
       Linux supports the standard  signals  listed  below.   The  second  column  of  the  table
       indicates which standard (if any)  specified the signal: "P1990" indicates that the signal
       is described in the original POSIX.1-1990 standard; "P2001" indicates that the signal  was
       added in SUSv2 and 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    Emulator trap
       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 (BSD 4.2)
       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
                                      readers; see 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    Bad system call (SVr4);
                                      see also 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 (BSD 4.2)
       SIGUSR1      P1990     Term    Sygnał 1 użytkownika
       SIGUSR2      P1990     Term    Sygnał 2 użytkownika
       SIGVTALRM    P2001     Term    Wirtualny zegar alarmu (BSD 4.2)
       SIGXCPU      P2001     Core    Przekroczone ogran. czasu CPU (BSD 4.2)
                                      see setrlimit(2)
       SIGXFSZ      P2001     Core    Przekr. ogran. rozmiaru pliku (BSD 4.2)
                                      see setrlimit(2)
       SIGWINCH       -        Ign    Sygnał zmiany rozm. okna (BSD 4.3, 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.

   Queueing and delivery semantics for standard signals
       If multiple standard signals are pending for a process, the order in which the signals are
       delivered is unspecified.

       Standard  signals  do not queue.  If multiple instances of a standard signal are generated
       while that signal is blocked, then only one instance of the signal is  marked  as  pending
       (and  the  signal  will be delivered just once when it is unblocked).  In the case where a
       standard signal is already pending, the siginfo_t structure (see sigaction(2))  associated
       with that signal is not overwritten on arrival of subsequent instances of the same signal.
       Thus, the process will receive the information associated with the first instance  of  the
       signal.

   Signal numbering for standard signals
       The  numeric  value  for  each signal is given in the table below.  As shown in the table,
       many signals have different numeric values on different architectures.  The first  numeric
       value in each table row shows the signal number on x86, ARM, and most other architectures;
       the second value is for Alpha and SPARC; the third is  for  MIPS;  and  the  last  is  for
       PARISC.  A dash (-) denotes that a signal is absent on the corresponding architecture.

       Sygnał        x86/ARM     Alpha/   MIPS   PARISC   Uwagi
                   most others   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                                            Same as SIGIO
       SIGPWR          30         29/-     19      19
       SIGINFO          -         29/-     -       -
       SIGLOST          -         -/29     -       -
       SIGSYS          31          12      12      31
       SIGUNUSED       31          -       -       31

       Note the following:

       •  Where  defined, SIGUNUSED is synonymous with SIGSYS.  Since glibc 2.26, SIGUNUSED is no
          longer defined on any architecture.

       •  Signal 29 is SIGINFO/SIGPWR (synonyms for the same  value)  on  Alpha  but  SIGLOST  on
          SPARC.

   Sygnały czasu rzeczywistego
       Starting  with  Linux  2.2,  Linux supports real-time signals as originally defined in the
       POSIX.1b real-time extensions (and now included in POSIX.1-2001).  The range of  supported
       real-time  signals  is defined by the macros SIGRTMIN and SIGRTMAX.  POSIX.1-2001 requires
       that an implementation support at least _POSIX_RTSIG_MAX (8) real-time signals.

       Jądro Linuksa 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ślą akcją na nieobsłużony sygnał czasu rzeczywistego jest przerwanie procesu, który go
       otrzymał.

       Sygnały czasu rzeczywistego są rozpoznawane w następujący sposób:

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

       According  to  POSIX,  an  implementation  should permit at least _POSIX_SIGQUEUE_MAX (32)
       real-time signals to be queued to a process.  However, Linux does things differently.   Up
       to  and  including  Linux 2.6.7, Linux imposes a system-wide limit on the number of queued
       real-time signals for all processes.  This  limit  can  be  viewed  and  (with  privilege)
       changed     via     the     /proc/sys/kernel/rtsig-max     file.     A    related    file,
       /proc/sys/kernel/rtsig-nr, can be  used  to  find  out  how  many  real-time  signals  are
       currently   queued.   In  Linux  2.6.8,  these  /proc  interfaces  were  replaced  by  the
       RLIMIT_SIGPENDING resource limit, which specifies a per-user limit for queued signals; see
       setrlimit(2)  for further details.

       The  addition  of  real-time  signals  required  the  widening of the signal set structure
       (sigset_t)  from 32 to 64 bits.  Consequently, various system calls were superseded by new
       system  calls  that supported the larger signal sets.  The old and new system calls are as
       follows:

       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.

       If a blocked call to one of the following interfaces is interrupted by a  signal  handler,
       then  the  call  is  automatically  restarted  after  the  signal  handler  returns if the
       SA_RESTART flag was used; otherwise the call fails with the error 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  timeout  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)   from  an  inotify(7)   file  descriptor  (since Linux 3.8; beforehand, always
          failed with 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 timeout 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 timeout 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ć.

       In certain circumstances, the seccomp(2)  user-space  notification  feature  can  lead  to
       restarting  of  system  calls  that  would otherwise never be restarted by SA_RESTART; for
       details, see 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 timeout 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 timeout gniazda (SO_RCVTIMEO) za  pomocą
          setsockopt(2):  connect(2),  send(2),  sendto(2)  i sendmsg(2), jeśli ustawiono timeout
          wysyłania danych(SO_SNDTIMEO).

       •  epoll_wait(2), epoll_pwait(2).

       •  semop(2), semtimedop(2).

       •  sigtimedwait(2), sigwaitinfo(2).

       •  Linux 3.7 and earlier: read(2)  from an inotify(7)  file descriptor

       •  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

       For a discussion of async-signal-safe functions, see signal-safety(7).

       The /proc/[pid]/task/[tid]/status file contains various fields that show the signals  that
       a  thread  is  blocking  (SigBlk),  catching  (SigCgt), or ignoring (SigIgn).  (The set of
       signals that are caught or ignored will be the same across  all  threads  in  a  process.)
       Other  fields show the set of pending signals that are directed to the thread (SigPnd)  as
       well as the set of pending signals that are directed to the process as a  whole  (ShdPnd).
       The  corresponding  fields in /proc/[pid]/status show the information for the main thread.
       See proc(5)  for further details.

BŁĘDY

       There are six signals that can be delivered as a  consequence  of  a  hardware  exception:
       SIGBUS,  SIGEMT,  SIGFPE,  SIGILL,  SIGSEGV,  and  SIGTRAP.   Which  of  these  signals is
       delivered, for any given hardware exception, is not documented and does  not  always  make
       sense.

       For  example,  an  invalid  memory  access  that  causes  delivery  of  SIGSEGV on one CPU
       architecture may cause delivery of SIGBUS on another architecture, or vice versa.

       For another example, using the x86 int instruction with a forbidden argument  (any  number
       other  than  3  or  128)   causes  delivery of SIGSEGV, even though SIGILL would make more
       sense, because of how the CPU reports the forbidden operation to the kernel.

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

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