Provided by: manpages-pl_0.6-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ł.

       Wpisy  w  kolumnie  "Akcja"  tabeli określają domyślne zachowanie dla danego sygnału, jako
       jedno z następujących:

       Term   Domyślną akcją jest przerwanie procesu.

       Ign    Domyślną akcją jest zignorowanie sygnału.

       Core   Domyślną akcją jest przerwanie procesu i zapisanie obrazu pamięci (patrz core(5)).

       Stop   Domyślną akcją jest zatrzymanie procesu.

       Cont   Domyślną akcją jest kontynuowanie procesu, jeżeli jest obecnie zatrzymany.

       Proces może zmienić zachowanie się sygnału, używając sigaction(2) lub 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  (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.

       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.

       killpg(2)       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 procesu  lub  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ć wygenerowany (i w związku z tym oczekujący) dla procesu jako całości (np.
       wysłany za pomocą kill(2)) lub dla określonego wątku  (np.  niektóre  sygnały,  takie  jak
       SIGSEGV  lub  SIGPFPE,  generowane  w  konsekwencji  użycia  określonej  instrukcji języka
       maszynowego oraz sygnały wysłane za  pomocą  pthread_kill(2),  są  skierowane  do  wątku).
       Sygnał  skierowany  do procesu może być dostarczony do któregokolwiek z jego wątków, który
       nie blokuje tego sygnału. Jeżeli więcej niż jeden wątek  nie  blokuje  sygnału,  to  jądro
       dostarczy sygnał do przypadkowo wybranego wątku.

       Wątek  może  pobrać zbiór obecnie oczekujących sygnałów, używając sigpending(2). Zbiór ten
       będzie zawierał sygnały  oczekujące  skierowane  zarówno  do  całego  procesu,  jak  i  do
       wywołującego wątku.

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

   Sygnały standardowe
       Linux obsługuje wymienione poniżej sygnały standardowe. Numery niektórych sygnałów  zależą
       od  architektury,  co  pokazano  w  kolumnie  "Wartość".  Jeżeli  podano trzy wartości, to
       zazwyczaj pierwsza obowiązuje dla architektur alpha i  sparc,  środkowa  dla  x86,  arm  i
       większości  innych  architektów,  a ostatnia dla mips. Znak - oznacza, że sygnał dla danej
       architektury nie występuje.

       Najpierw sygnały opisane w pierwotnym standardzie POSIX.1-1990

       Sygnał    Wartość    Akcja   Komentarz
       ───────────────────────────────────────────────────────────────────────
       SIGHUP        1      Term    Zawieszenie wykryte na terminalu kontrol.
                                    lub śmierć procesu kontrolującego
       SIGINT        2      Term    Przerwanie nakazane z klawiatury
       SIGQUIT       3      Core    Wyjście nakazane z klawiatury

       SIGILL        4      Core    Nielegalna instrukcja
       SIGABRT       6      Core    Sygnał abort od abort(3)
       SIGFPE        8      Core    Wyjątek zmiennoprzecinkowy
       SIGKILL       9      Term    Sygnał Kill
       SIGSEGV      11      Core    Nieprawidłowa referencja pamięciowa
       SIGPIPE      13      Term    Uszkodzony potok: zapis do potoku bez
                                    odbiorców
       SIGALRM      14      Term    Sygnał timera od alarm(2)
       SIGTERM      15      Term    Sygnał zakończenia pracy
       SIGUSR1   30,10,16   Term    Sygnał 1 użytkownika
       SIGUSR2   31,12,17   Term    Sygnał 2 użytkownika
       SIGCHLD   20,17,18    Ign    Potomek zatrzymał się lub zakończył pracę
       SIGCONT   19,18,25   Cont    Kontynuuj, jeśli się zatrzymał
       SIGSTOP   17,19,23   Stop    Zatrzymaj proces
       SIGTSTP   18,20,24   Stop    Zatrzymanie napisane z terminala
       SIGTTIN   21,21,26   Stop    Wejście terminala dla procesu w tle
       SIGTTOU   22,22,27   Stop    Wyjście terminala dla procesu w tle

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

       Następnie sygnały niewystępujące  w  standardzie  POSIX.1-1990,  ale  opisane  w  SUSv2  i
       POSIX.1-2001.

       Sygnał      Wartość    Akcja   Komentarz
       ───────────────────────────────────────────────────────────────────────
       SIGBUS      10,7,10    Core    Błąd szyny (niepr. dostęp do pamięci)
       SIGPOLL                Term    Zdarzenie odpytywalne (Sys V).
                                      Synonim dla SIGIO
       SIGPROF     27,27,29   Term    Przeterminowanie zegara profilowego
       SIGSYS      12,31,12   Core    Niewłaściwy argument funkcji (SVr4)
       SIGTRAP        5       Core    Śledzenie/pułapka kontrolna
       SIGURG      16,23,21    Ign    Pilny warunek na gnieździe (BSD 4.2)
       SIGVTALRM   26,26,28   Term    Wirtualny zegar alarmu (BSD 4.2)
       SIGXCPU     24,24,30   Core    Przekroczone ogran. czasu CPU (BSD 4.2)
       SIGXFSZ     25,25,31   Core    Przekr. ogran. rozmiaru pliku (BSD 4.2)

       Do wersji 2.2 Linuksa (włącznie) domyślne zachowanie dla sygnałów SIGSYS, SIGXCPU, SIGXFSZ
       oraz (na architekturach innych niż SPARC i MIPS) SIGBUS  polegało  na  przerwaniu  procesu
       (bez  zrzutu  pamięci).  (W  niektórych  innych Uniksach domyślne zachowanie dla SIGXCPU i
       SIGXFSZ polega na przerwaniu procesu  bez  zrzutu  pamięci).  Linux  2.4  jest  zgodny  ze
       wymaganiami  standardu POSIX.1-2001 dotyczącymi tych sygnałów i przerywa proces ze zrzutem
       pamięci.

       A teraz różne inne sygnały.

       Sygnał      Wartość    Akcja   Komentarz
       ───────────────────────────────────────────────────────────────────────
       SIGIOT         6       Core    pułapka IOT. Synonim SIGABRT
       SIGEMT       7,-,7     Term
       SIGSTKFLT    -,16,-    Term    Błąd stosu koprocesora (nieużywany)
       SIGIO       23,29,22   Term    I/O teraz możliwe (BSD 4.2)
       SIGCLD       -,-,18     Ign    Synonim SIGCHLD
       SIGPWR      29,30,19   Term    Błąd zasilania (System V)
       SIGINFO      29,-,-            Synonim SIGPWR
       SIGLOST      -,-,-     Term    Utracono blokadę pliku (nieużywane)
       SIGWINCH    28,28,20    Ign    Sygnał zmiany rozm. okna (BSD 4.3, Sun)
       SIGUNUSED    -,31,-    Core    Synonimiczny z SIGSYS

       (Sygnał 29 oznacza SIGINFO / SIGPWR na architekturze alpha, lecz SIGLOST na  architekturze
       sparc).

       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.

       Na  większości  architektur,  jeśli  SIGUNUSED  jest  zdefiniowany,  to jest synonimem dla
       SIGSYS.

   Sygnały czasu rzeczywistego
       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  Linuksa  wspiera  32  różne  sygnały  czasu  rzeczywistego, o numerach od 33 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:

       1.  Można kolejkować wiele egzemplarzy sygnału czasu rzeczywistego. Dla odróżnienia, jeśli
           w czasie gdy standardowy sygnał jest blokowany zostanie doręczonych wiele  egzemplarzy
           tego sygnału, tylko jeden egzemplarzy trafia do kolejki.

       2.  Jeśli  sygnał  wysłano  korzystając  z  sigqueue(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ł.

       3.  Sygnały  czasu  rzeczywistego są doręczane w zagwarantowanej kolejności. Sygnały czasu
           rzeczywistego jednego rodzaju są doręczane  w  takiej  kolejności,  w  jakiej  zostały
           wysłane.  Jeśli do procesu zostaną wysłane różne sygnały czasu rzeczywistego, będą one
           doręczone począwszy od sygnału o najniższym numerze. (Tzn. sygnały o niskich  numerach
           mają  najwyższy  priorytet).  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   wersji   jądra   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.

   Funkcje bezpieczne podczas asynchronicznego przetwarzania sygnałów
       Funkcja  obsługi  sygnału musi być bardzo ostrożna, ponieważ przetwarzanie w innym miejscu
       może być przerwane w przypadkowym punkcie  wykonywaniu  programu.  POSIX  zawiera  pojęcie
       "funkcji  bezpiecznych".  Jeśli  sygnał  przerwie  przetwarzanie  funkcji niebezpiecznej i
       procedura obsługi sygnału również wywoła funkcję  niebezpieczną,  to  zachowanie  programu
       jest niezdefiniowane.

       POSIX.1-2004  (znany także jako POSIX.1-2001 Technical Corrigendum 2) wymaga implementacji
       sygnałów dających gwarancję, że następujące funkcje  można  bezpiecznie  wywołać  wewnątrz
       funkcji obsługi sygnału:

           _Exit()
           _exit()
           abort()
           accept()
           access()
           aio_error()
           aio_return()
           aio_suspend()
           alarm()
           bind()
           cfgetispeed()
           cfgetospeed()
           cfsetispeed()
           cfsetospeed()
           chdir()
           chmod()
           chown()
           clock_gettime()
           close()
           connect()
           creat()
           dup()
           dup2()
           execle()
           execve()
           fchmod()
           fchown()
           fcntl()
           fdatasync()
           fork()
           fpathconf()
           fstat()
           fsync()
           ftruncate()
           getegid()
           geteuid()
           getgid()
           getgroups()
           getpeername()
           getpgrp()
           getpid()
           getppid()
           getsockname()
           getsockopt()
           getuid()
           kill()
           link()
           listen()
           lseek()
           lstat()
           mkdir()
           mkfifo()
           open()
           pathconf()
           pause()
           pipe()
           poll()
           posix_trace_event()
           pselect()
           raise()
           read()
           readlink()
           recv()
           recvfrom()
           recvmsg()
           rename()
           rmdir()
           select()
           sem_post()
           send()
           sendmsg()
           sendto()
           setgid()
           setpgid()
           setsid()
           setsockopt()
           setuid()
           shutdown()
           sigaction()
           sigaddset()
           sigdelset()
           sigemptyset()
           sigfillset()
           sigismember()
           signal()
           sigpause()
           sigpending()
           sigprocmask()
           sigqueue()
           sigset()
           sigsuspend()
           sleep()
           sockatmark()
           socket()
           socketpair()
           stat()
           symlink()
           sysconf()
           tcdrain()
           tcflow()
           tcflush()
           tcgetattr()
           tcgetpgrp()
           tcsendbreak()
           tcsetattr()
           tcsetpgrp()
           time()
           timer_getoverrun()
           timer_gettime()
           timer_settime()
           times()
           umask()
           uname()
           unlink()
           utime()
           wait()
           waitpid()
           write()

       POSIX.1-2008  usuwa  z  powyższej  listy  funkcje fpathconf(), pathconf() i sysconf() oraz
       dodaje następujące funkcje:

           execl()
           execv()
           faccessat()
           fchmodat()
           fchownat()
           fexecve()
           fstatat()
           futimens()
           linkat()
           mkdirat()
           mkfifoat()
           mknod()
           mknodat()
           openat()
           readlinkat()
           renameat()
           symlinkat()
           unlinkat()
           utimensat()
           utimes()

   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 (dysk
             zgodnie  z  tą  definicją  nie jest urządzeniem powolnym). 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).

           * 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 plików blokujących: flock(2) i F_SETLKW z 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).

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

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

           * read(2) czytające z deskryptora pliku inotify(7).

           * 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ć.

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

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

ZGODNE Z

       POSIX.1, z wyjątkami jak podano.

ZOBACZ TAKŻE

       kill(1),  getrlimit(2),  kill(2),   killpg(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),  sigsuspend(2),  sigwaitinfo(2),   abort(3),
       bsd_signal(3),   longjmp(3),   raise(3),   pthread_sigqueue(3),   sigqueue(3),  sigset(3),
       sigsetops(3),  sigvec(3),  sigwait(3),  strsignal(3),  sysv_signal(3),  core(5),  proc(5),
       pthreads(7), sigevent(7)

O STRONIE

       Angielska  wersja  tej  strony  pochodzi  z  wydania  3.71  projektu Linux man-pages. Opis
       projektu, informacje dotyczące zgłaszania błędów, oraz najnowszą  wersję  oryginału  można
       znaleźć pod adresem http://www.kernel.org/doc/man-pages/.

TŁUMACZENIE

       Autorami  polskiego  tłumaczenia niniejszej strony podręcznika man są: Przemek Borys (PTM)
       <pborys@p-soft.silesia.linux.org.pl>, Robert Luberda <robert@debian.org> i  Michał  Kułach
       <michal.kulach@gmail.com>.

       Polskie  tłumaczenie jest częścią projektu manpages-pl; uwagi, pomoc, zgłaszanie błędów na
       stronie  http://sourceforge.net/projects/manpages-pl/.  Jest   zgodne   z   wersją    3.71
       oryginału.