後述の表の "動作" の欄のエントリは各シグナルのデフォルトの 処理方法を示しており、以下のような意味を持つ。
プロセスは、 sigaction(2) や signal(2) を使って、シグナルの処理方法を変更することができる (signal(2) の方が移植性は低い)。シグナルの配送時に起こる動作として プロセスが選択できるのは、次のいずれか一つである。 デフォルトの動作を実行する、シグナルを無視する、 シグナルハンドラ (signal handler) でシグナルを捕捉する。シグナルハンドラとは、シグナル配送時に 自動的に起動されるプログラマ定義の関数である。 (デフォルトでは、シグナルハンドラは通常のプロセスのスタック上で起動される。 シグナルハンドラが代替スタック (alternate stack) を使用するように設定する こともできる。代替スタックを使用するように設定する方法と、どのような際に 代替スタックが役に立つかについての議論については sigaltstack(2) を参照のこと。
シグナルの処理方法はプロセス単位の属性である。 マルチスレッドのアプリケーションでは、あるシグナルの処理方法は 全てのスレッドで同じである。
fork(2) で作成された子プロセスは親プロセスのシグナルの処理方法のコピーを継承する。 execve(2) の間、ハンドラが登録されているシグナルの処理方法はデフォルトにリセット され、無視となっているシグナルの処理方法は変更されずそのままとなる。
プロセス内の各スレッドは、それぞれ独立な シグナルマスク (signal mask) を持つ。シグナルマスクはそのスレッドが現在ブロックしている シグナル集合を示すものである。 スレッドは、 pthread_sigmask(3) を使って自分のシグナルマスクを操作できる。 伝統的なシングルスレッドのアプリケーションでは、 sigprocmask(2) を使って、シグナルマスクを操作できる。
fork(2) 経由で作成された子プロセスは、 親プロセスのシグナルマスクのコピーを継承する。 execve(2) の前後でシグナルマスクは保持される。
生成されるシグナル (したがって処理待ちとなるシグナル) には、 プロセス全体宛てと特定のスレッド宛てがある。 例えば、プロセス全体宛てのシグナルは kill(2) を使って送信される。 特定のマシン語の命令の実行の結果として生成される、 SIGSEGV や SIGFPE などのシグナルは、スレッド宛てとなる。 また、 pthread_kill(3) を使って特定のスレッド宛てに生成されたシグナルも スレッド宛てとなる。 プロセス宛てのシグナルは、そのシグナルをブロックしていないスレッドのうち いずれかの一つに配送することができる。そのシグナルをブロックしていない スレッドが複数ある場合、シグナルを配送するスレッドはカーネルが 無作為に選択する。
スレッドは、 sigpending(2) を使って、現在処理待ちのシグナル集合を取得することができる。 この集合は、プロセス宛ての処理待ちシグナルと 呼び出したスレッド宛てのシグナルの両方から構成される。
fork(2) 経由で作成された子プロセスでは、処理待ちのシグナル集合は 空の集合で初期化される。 execve(2) の前後で、処理待ちのシグナル集合は保持される。
最初に、POSIX.1-1990 に定義されているシグナルを示す。
| シグナル | 値 | 動作 | コメント |
| SIGINT | 2 | Term | キーボードからの割り込み (Interrupt) |
| SIGQUIT | 3 | Core | キーボードによる中止 (Quit) |
| SIGILL | 4 | Core | 不正な命令 |
| SIGABRT | 6 | Core | abort(3) からの中断 (Abort) シグナル |
| SIGFPE | 8 | Core | 浮動小数点例外 |
| SIGKILL | 9 | Term | Kill シグナル |
| SIGSEGV | 11 | Core | 不正なメモリ参照 |
| SIGPIPE | 13 | Term | パイプ破壊: 読み手の無いパイプへの書き出し |
| SIGALRM | 14 | Term | alarm(2) からのタイマーシグナル |
| SIGTERM | 15 | Term | 終了 (termination) シグナル |
| SIGUSR1 | 30,10,16 | Term | ユーザ定義シグナル 1 |
| SIGUSR2 | 31,12,17 | Term | ユーザ定義シグナル 2 |
| SIGCHLD | 20,17,18 | Ign | 子プロセスの一時停止 (stop) または終了 |
| SIGCONT | 19,18,25 | Cont | 一時停止 (stop) からの再開 |
| SIGSTOP | 17,19,23 | Stop | プロセスの一時停止 (stop) |
| SIGTSTP | 18,20,24 | Stop | 端末 (tty) より入力された一時停止 (stop) |
| SIGTTIN | 21,21,26 | Stop | バックグランドプロセスの tty 入力 |
| SIGTTOU | 22,22,27 | Stop | バックグランドプロセスの tty 出力 |
シグナル SIGKILL と SIGSTOP はキャッチ、ブロック、無視できない。
次に、 POSIX.1-1990 標準にはないが、 SUSv2 と POSIX.1-2001 に記述されているシグナルを示す。
| シグナル | 値 | 動作 | コメント |
| SIGPOLL | Term | ポーリング可能なイベント (Sys V)。 | |
| SIGIO と同義 | |||
| SIGPROF | 27,27,29 | Term | profiling タイマの時間切れ |
| SIGSYS | 12,31,12 | Core | ルーチンへの引き数が不正 (SVr4) |
| SIGTRAP | 5 | Core | トレース/ブレークポイント トラップ |
| SIGURG | 16,23,21 | Ign |
ソケットの緊急事態 (urgent condition) (4.2BSD)
|
| SIGVTALRM | 26,26,28 | Term | 仮想アラームクロック (4.2BSD) |
| SIGXCPU | 24,24,30 | Core | CPU時間制限超過 (4.2BSD) |
| SIGXFSZ | 25,25,31 | Core | ファイルサイズ制限の超過 (4.2BSD) |
Linux 2.2 以前では、 SIGSYS, SIGXCPU, SIGXFSZ および SPARC と MIPS 以外のアーキテクチャでの SIGBUS のデフォルトの振る舞いは (コアダンプ出力なしの) プロセス終了であった。 (他の Unix システムにも SIGXCPU と SIGXFSZ のデフォルトの動作がコアダンプなしのプロセス終了のものがある。) Linux 2.4 では、POSIX.1-2001 での要求仕様に準拠して、 これらのシグナルで、プロセスを終了させ、コアダンプを出力する ようになっている。
次にその他の各種シグナルを示す。
| シグナル | 値 | 動作 | コメント |
| SIGEMT | 7,-,7 | Term | |
| SIGSTKFLT | -,16,- | A |
数値演算プロセッサにおけるスタックフォルト (未使用)
|
| SIGIO | 23,29,22 | Term | 入出力が可能になった (4.2BSD) |
| SIGCLD | -,-,18 | Ign | SIGCHLD と同義 |
| SIGPWR | 29,30,19 | Term | 電源喪失 (Power failure) (System V) |
| SIGINFO | 29,-,- | SIGPWR と同義 | |
| SIGLOST | -,-,- | Term | ファイルロックが失われた |
| SIGWINCH | 28,28,20 | Ign |
ウィンドウ リサイズ シグナル (4.3BSD, Sun)
|
| SIGUNUSED | -,31,- | Core | SIGSYS と同義 |
(シグナル 29 は alpha では SIGINFO / SIGPWR だが、sparc では SIGLOST である。)
SIGEMT は POSIX.1-2001 に規定されていないが、 その他の多くの Unix システムに存在する。 デフォルトの動作は多くの場合、コアダンプ出力を伴うプロセスの終了である。
SIGPWR は (POSIX.1-2001 に規定されていないが) このシグナルが存在する 他の Unix システムでは多くの場合、デフォルト動作は無視である。
SIGIO は (POSIX.1-2001 に規定されていないが) いくつかの他の Unix システムでは デフォルト動作は無視である。
SIGUNUSED が定義されている場合には、ほとんどのアーキテクチャで SIGSYS の同義語となっている。
Linux は、32 個の異なるリアルタイムシグナルに対応しており、 その番号は 33 から 64 である。 しかしながら、glibc の POSIX スレッド実装は、 内部で 2個 (NPTL の場合) か 3個 (LinuxThreads の場合) の リアルタイムシグナルを使用しており (pthreads(7) 参照)、 SIGRTMIN の値を適切に (34 か 35 に) 調整する。 利用可能なリアルタイムシグナルの範囲は glibc のスレッド実装により 異なるし (使用するカーネルと glibc により実行時にも変化する)、 Unix システムの種類によっても異なる。したがって、 プログラムでは「ハードコーディングした数字を使ってのリアルタイムシグナルの 参照は決してすべきではなく」、代わりに SIGRTMIN+n の形で参照すべきである。また、 SIGRTMIN+n が SIGRTMAX を超えていないかのチェックを (実行時に) 適切に行うべきである。
標準シグナルと異なり、リアルタイムシグナルには 事前に定義された意味はない。 リアルタイムシグナルの全部をアプリケーションで定義した用途に使える。 (但し、LinuxThreads 実装で、リアルタイムシグナルの番号のうち 最初の 3つが使用されている点に注意すること)
ハンドリングしないリアルタイムシグナルのデフォルトの動作は 受信したプロセスの終了である。
リアルタイムシグナルは以下の特徴がある:
一つのプロセスに対して標準シグナルとリアルタイムシグナルの両方が 処理待ちの場合、POSIX はどちらが先に配送されるかを規定していない。 Linux では、他の多くの実装と同様、このような場合には 標準シグナルが優先される。
POSIX によれば、1 プロセス毎に最低 _POSIX_SIGQUEUE_MAX (32) 個のリアルタイムシグナルをキューに入れられるべきとしている。 しかし、 Linux では違った実装になっている。カーネル 2.6.7 までは (2.6.7 を含む)、全プロセスでキューに入っているリアルタイムシグナル の数の合計についてシステム全体での制限がある。 この制限は /proc/sys/kernel/rtsig-max ファイルで見ることができ、 (権限があれば) 変更もできる。 関係するファイルとして、 /proc/sys/kernel/rtsig-nr を見ることで、いくつのリアルタイムシグナルが現在キューに入っているかを 知ることができる。 Linux 2.6.8 で、これらの /proc 経由のインターフェースは、 RLIMIT_SIGPENDING リソース制限に置き換えられた。 これは、キューに入るシグナル数に関してユーザ単位に 上限を指定するものである。 詳しくは setrlimit(2) を参照。
他の場所の処理はプログラム実行の任意の箇所で中断されるため、 sigaction(2) や signal(2) で登録するシグナルハンドラ関数には非常に注意しなければならない。 POSIX には「安全な関数 (safe function)」という概念がある。 シグナルが安全でない関数の実行を中断し、かつ handler が安全でない関数を呼び出した場合、プログラムの挙動は未定義である。
POSIX.1-2004 (POSIX.1-2001 Technical Corrigendum (正誤表) 2 とも言う) では、 シグナルハンドラ内での安全な呼び出しを保証することが必須の関数として 以下が規定されている。
_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 では、上記のリストのうち fpathconf(), pathconf(), sysconf() が削除され、以下の関数が追加された。
execl() execv() faccessat() fchmodat() fchownat() fexecve() fstatat() futimens() linkat() mkdirat() mkfifoat() mknod() mknodat() openat() readlinkat() renameat() symlinkat() unlinkat() utimensat() utimes()
これらの二つの挙動のうちどちらが起こるかは、インターフェイスにより依存し、 シグナルハンドラが SA_RESTART フラグ (sigaction(2) 参照) を使って設定されていたかにも依存する。 詳細は Unix システムによって異なる。 Linux における詳細を以下で説明する。
以下のインターフェイスのいずれかの呼び出しが停止している間に シグナルハンドラにより割り込まれた場合、 SA_RESTART フラグが使用されていれば、シグナルハンドラが返った後に その呼び出しは自動的に再スタートされることになる。 それ以外の場合は、その呼び出しはエラー EINTR で失敗することになる。
以下のインターフェイスは、 SA_RESTART を使っているどうかに関わらず、シグナルハンドラにより割り込まれた後、 再スタートすることは決してない。 これらは、シグナルハンドラにより割り込まれると、常にエラー EINTR で失敗する。
sleep(3) 関数も、ハンドラにより割り込まれた場合、決して再スタートされることはない。 しかし、成功となり、残っている停止時間を返す。
この挙動を示す Linux のインターフェイスは以下の通りである。