Manpages

JMÉNO

signal − přehled signálů

POPIS

V Linuxu jsou podporovány jak POSIX reliable signály (dále jen "standardní signály"), tak POSIX real−time signály.

Dispozice signálů
Každý signál má dispozici, která určuje, jak se proces zachová při jeho přijetí.

Údaje ve sloupci "Akce" níže uvedených tabulek určují výchozí dipozici každého signálu následujícně:

Proces může změnit dispozici signálu pomocí sigaction(2) nebo (méně přenositelně) signal(2). Pomocí těchto systémových volání může proces vybrat jedno z následujících chování, které má nastat po přijetí signálu: provést výchozí akci; ignorovat signál; nebo zachytit signál pomocí signal handleru, programátorem definovanou funkcí, která je automaticky volána při přijetí signálu. (By default, the 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.)

Dispozice signálu je atribut procesu: v mnohovláknových aplikacích je dispozice určitého signálu stejná pro všechna vlákna.

A child created via fork(2) inherits a copy of its parent’s signal dispositions. During an execve(2), the dispositions of handled signals are reset to the default; the dispositions of ignored signals are left unchanged.

Poslání signálu
The following system calls and library functions allow the caller to send a signal:

Waiting for a Signal to be Caught
The following system calls suspend execution of the calling process or thread until a signal is caught (or an unhandled signal terminates the process):

Synchronously Accepting a Signal
Rather than asynchronously catching a signal via a signal handler, it is possible to synchronously accept the signal, that is, to block execution until the signal is delivered, at which point the kernel returns information about the signal to the caller. There are two general ways to do this:

Maska signálu a nevyřízené signály
Signál může být blokován, tj. nebude přijat, dokud nebude odblokován. V mezidobí mezi vygenerovánim signálu a jeho přijetím je signál tzv. nevyřízený.

Každé vlákno procesu má nezávislou masku signálu, která určuje sadu signálů, kterou vlákno právě blokuje. Vlákno může manipulovat svou maskou signálu pomocí pthread_sigmask(3). V klasické jednovláknové aplikaci může být k manipulaci maskou signálu použito sigprocmask(2).

A child created via fork(2) inherits a copy of its parent’s signal mask; the signal mask is preserved across execve(2).

Signál může být vygenerován (a tedy nevyřízený) pro proces jako celek (např. posláním pomocí kill(2)) nebo pro určité vlákno (např. některé signály jako SIGSEGV a SIGFPE, vygenerované jako důsledek spuštění určité instrukce strojového jazyka, jsou vláknově orientovány, stejně jako signály zaměřené na určité vlákno pomocí pthread_kill(3)). Signál zaměřený na vlákno může být doručen jakémukoliv vláknu, které jej právě neblokuje. Pokud signál neblokuje více vláken, vybere příjemce signálu jádro.

Vlákno může získat sadu signálů, které jsou momentálně nevyřízené, pomocí sigpending(2). Tato sada se skládá ze sloučení sady nevyřízených signálů zaměřených na proces a sady signálů zaměřených na volající vlákno.

A child created via fork(2) initially has an empty pending signal set; the pending signal set is preserved across an execve(2).

Standardní Signály
Linux podporuje níže uvedené standardní signály. Některá čísla signálů jsou závislá na architektuře, jak je uvedeno ve sloupci "Hodnota". (Kde jsou uvedeny tři hodnoty, první obvykle platí pro alpha a sparc, prostřední pro i386, ppc a sh a poslední pro mips. Znak − znamená, že signál v odpovídající architektuře chybí.)

Nejprve jsou uvedeny signály popsané v normě POSIX.1−1990.

Signály SIGKILL a SIGSTOP nemohou být zachyceny, blokovány ani ignorovány.

Následují signály nad rámec standardu POSIX.1−1990, které jsou popsány v SUSv2 a POSIX.1−2001.

Až po Linux 2.2 včetně bylo výchozí chování pro SIGSYS, SIGXCPU, SIGXFSZ, a (na architekturách jiných než SPARC a MIPS) SIGBUS ukončit proces (bez core dump). (Na některých jiných Unixových systémech bylo výchozí akcí pro SIGXCPU a SIGXFSZ ukončení procesu bez core dump.) Linux 2.4 splňuje požadavky POSIX.1−2001 pro tyto signály, ukončuje procesy s core dump.

Další různé signály.

Signál č. 29 na procesorech Alpha znamená SIGINFO / SIGPWE, ale na Sparcu SIGLOST.)

SIGEMT není specifikován v POSIX.1−2001, ale stejně je přítomen na většině ostatních Unixových systémů, kde je výchozí akcí obvykle ukončení procesu s core dump.

SIGPWR (není specifikován v POSIX.1−2001) na většině ostatních Unixových systémů, kde se objevuje, je obvykle ignorován.

SIGIO (není specifikován v POSIX.1−2001) na některých dalších Unixech je jako výchozí ignorován.

Real−time signály
Linux podporuje real−time signály tak, jak jsou definovány v POSIX.1b real−time extensions (a nyní zahrnuty v POSIX.1−2001). Rozsah podporovaných real−time signálů je definován makry SIGRTMIN a SIGRTMAX. POSIX.1−2001 vyžaduje, aby implementace podporovale alespoň _POSIX_RTSIG_MAX (8) real−time signálů.

Linux podporuje 32 různých real−time signálů očíslovaných 33 až 64. Nicméně implementace POSIX threads v glibc používá interně dva (pro NPTL) nebo tři (pro LinuxThreads) real−time signály (viz pthreads(7)), a podle toho upravuje hodnotu SIGRTMIN (na 34 nebo 35). protože rozsah dostupných real−time signálů se liší v závislosti na implementaci vláken v glibc (může se měnit za běhu v závislosti na jádře a glibc) a navíc rozsah real−time signálů se mezi Unixovými systémy liší, programy by nikdy neměly odkazovat na real−time signály pevně danými čísly, místo toho by měly používat notaci SIGRTMIN+n, a za běhu kontrolovat, zda SIGRTMIN+n nepřesahuje SIGRTMAX.

Na rozdíl od standardních signálů nemají real−time signály stanovený význam: Celá sada real−time signálů může být použita pro účely definované aplikací. (Nicméně pozor, první tři real−time signály používá implementace LinuxThreads.)

Výchozí akcí pro nezpracovaný real−time signál je ukončení procesu, který jej přijal.

Real−time signály se liší následujícně:

Pokud má proces nevyřízené zároveň real−time a standardní signály, POSIX neurčuje, které mají být doručeny jako první. Linux, stejně jako mnoho jiných implementací, v takovém případě upřednostňí standardní signály.

Podle POSIX by měla implementace pro frontu procesu povolit alespoň _POSIX_SIGQUEUE_MAX (32) real−time signálů. Linux ale pracuje jinak. V jádrech do 2.6.7 včetně stanovuje Linux celosystémový limit na počet real−time signálů ve frontách všech procesů. tento limit je možné zjistit a (s patřičnými právy) změnit přes soubor /proc/sys/kernel/rtsig−max. Další soubor, /proc/sys/kernel/rtsig−nr, může být použit ke zjištění, kolik real−time signálů je momentálně ve frontách. V Linuxu 2.6.8 byla tato /proc rozhraní nahrazena limitem zdrojů RLIMIT_SIGPENDING, který určuje uživatelský limit na počet signálů ve frontách; více viz setrlimit(2).

Async−signal−safe functions
Rutina zpracovávající signál, kterou vytvořil sigaction(2) nebo signal(2), musí být velmi opatrná, neboť její zpracování může být v určitých místech programu přerušeno. POSIX má koncept "bezpečné funkce". Pokud signál přeruší vykonávání ne−bezpečné funkce a handler zavolá ne−bezpečnou funkci, potom je chování programu nedefinováno.

POSIX.1−2004 (také známý jako POSIX.1−2001 Technical Corrigendum 2) vyžaduje, aby implementace zaručovala bezpečné volání následujících funkcí v rámci "signal handleru":

_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 odstraňuje fpathconf(), pathconf() a sysconf() z uvedeného seznamu a přidává následující funkce:

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

Přerušení systémových volání a funkcí knihoven prostřednictvím "signal handlers"
Pokud je signal handler vyvolán v okamžiku, kdy je systémové volání nebo funkce knihovny blokována, pak:

Která z těchto možností nastane, záleží na rozhraní a na tom, zda byl signal handler definován s pomocí vlajky SA_RESTART (viz sigaction(2)). Podrobnosti se mezi Unixovými systémy liší; dále jsou uvedeny pro Linux.

Pokud je blokované volání pro jedno z následujících rozhraní přerušeno signal handlerem a byla použita vlajka SA_RESTART, je volání automaticky restartováno po návratu signal handleru. V opačném případě volání selže s chybou EINTR:

Následující rozhraní se po přerušení signal handlerem nikdy nerestartují, bez ohledu na použití SA_RESTART − vždycky selžou s chybou EINTR:

Funkce sleep(3) se také při přerušení signal handlerem nerestartuje, nýbrž vrátí úspěch: počet sekund, které zbývají ke spaní.

Přerušení systémovách volání a funkcí knihoven signály Stop
V Linuxu mohou některá blokující rozhraní selhat s chybou EINTR i bez signal handlerů, pokud je proces zastaven jedním ze stop signálů a poté obnoven pomocí SIGCONT. Toto chování neodporuje POSIX.1 a neobjevuje se v jiných systémech.

Linuxová rozhraní, v nichž se toto chování projevuje, jsou:

SPLŇUJE STANDARDY

POSIX.1, s uvedenými výjimkami.

CHYBY

Signály SIGIO a SIGLOST mají stejnou hodnotu. SIGLOST se ve zdrojových textech jádra již nepoužívá, ale při překladu určitých balíků software se stále předpokládá, že signál č.29 znamená SIGLOST.

DALŠÍ INFORMACE

kill(1), getrlimit(2), kill(2), killpg(2), setitimer(2), setrlimit(2), sgetmask(2), sigaction(2), sigaltstack(2), signal(2), signalfd(2), sigpending(2), sigprocmask(2), sigqueue(2), sigsuspend(2), sigwaitinfo(2), abort(3), bsd_signal(3), longjmp(3), raise(3), sigset(3), sigsetops(3), sigvec(3), sigwait(3), strsignal(3), sysv_signal(3), core(5), proc(5), pthreads(7)

TIRÁŽ

Tato stránka je součástí projektu Linux man−pages. Popis projektu a informace o hlášení chyb najdete na http://www.kernel.org/doc/man−pages/.