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.