1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
|
.TH SIGNAL 2
.CT 2 proc_man
.SH NAME
signal, kill \(mi receive and send signals
.SH SYNOPSIS
.nf
.B #include <signal.h>
.PP
.B SIG_TYP (*signal(sig, func))()
.B SIG_TYP (*func)();
.PP
.B int kill(pid, sig)
.fi
.SH DESCRIPTION
A signal
is generated by some abnormal event
initiated by a user at a terminal (quit, interrupt),
by a program error (bus error, etc.),
or by
.I kill
in another process.
Normally, most signals
cause termination of the receiving process,
but
.I signal
allows them either to be ignored
or to be caught by interrupting to a specified function.
The following signal names are defined in
.FR <signal.h> :
.LP
.nf
.ta \w'SIGMMMM 'u +\w'15* 'u
\fLSIGHUP\fP 1 hangup
\fLSIGINT\fP 2 interrupt
\fLSIGQUIT\fP 3* quit
\fLSIGILL\fP 4* illegal instruction (not reset when caught)
\fLSIGTRAP\fP 5* trace trap (not reset when caught)
\fLSIGIOT\fP 6* IOT instruction
\fLSIGEMT\fP 7* EMT instruction
\fLSIGFPE\fP 8* floating point exception
\fLSIGKILL\fP 9 kill (cannot be caught or ignored)
\fLSIGBUS\fP 10* bus error
\fLSIGSEGV\fP 11* segmentation violation
\fLSIGSYS\fP 12* bad argument to system call
\fLSIGPIPE\fP 13 write on a pipe with no one to read it
\fLSIGALRM\fP 14 alarm clock
\fLSIGTERM\fP 15 software termination signal
16 unassigned
\fLSIGSTOP\fP 17+ stop (cannot be caught or ignored)
\fLSIGCONT\fP 19# continue a stopped process
\fLSIGCHLD\fP 20# child has stopped or exited
\fLSIGLAB\fP 26# file descriptor label change (not reset when caught)
.sp
.fi
* places core image in file
.B core
if not caught or ignored
.br
+ suspends process until
.B SIGCONT
or
.BR PIOCRUN ;
see
.IR proc (4)
.br
# ignored if not caught
.PP
Signals 1 through
.BR NSIG -1,
defined in the include file, exist.
Those not listed above have
no conventional meaning in this system.
(Berkeley systems use 1-15 and 17-25.)
.PP
.I Signal
specifies how signal
.I sig
will be handled.
If
.I func
is
.BR SIG_DFL ,
the default action listed above is reinstated.
If
.I func
is
.BR SIG_IGN ,
the signal will be ignored.
Otherwise the signal will be caught; when the signal occurs,
the function pointed to by
.IR func ,
say
.IR catcher (),
defined thus,
.EX
.L
int catcher(sig) { ... }
.EE
will be called with the
signal number as argument.
A return from the function will
continue the process at the point it was interrupted.
.PP
Except as indicated, a signal is reset to
.B SIG_DFL
after being caught.
Thus if it is desired to catch every such signal,
the catching routine must issue another
.I signal
call.
.PP
When a caught signal occurs
during certain system calls, the call terminates prematurely.
In particular this can occur during
.IR read
or
.IR write (2)
on a slow device (like a typewriter, but not a disc);
and during
.I pause
and
.IR wait (2).
The interrupted system call will return error
.BR EINTR .
The user's program may then, if it wishes, re-execute the call.
.PP
Core images are made exactly as if by
.IR creat (2)
and
.IR write (2).
However, no core image will be made for a process
that ever had capability
.BR T_NOCHK
or for a child of such a process until the child
successfully performs
.IR exec (2).
.PP
.I Signal
returns the previous (or initial)
value of
.I func
for the particular signal.
.PP
After a
.IR fork (2)
the child inherits all signal settings.
.IR Exec (2)
resets all caught signals to default action.
.PP
.I Kill
sends signal
.I sig
to the process specified by process id
.I pid.
Signal 0
has no effect on the target process and may be used to
test the existence of a process.
The success of sending a signal is independent of how the receiving
process treats the signal.
.PP
The effective userid of the sending process must be either 0
or the effective userid of the receiving process.
.PP
If
.I pid
is 0, the signal is sent to all other processes in the
sender's process group; see
.IR stream (4).
.PP
If
.I pid
is \-1, and the user is the super-user,
the signal is broadcast universally
except to processes 0 (scheduler),
1 (initialization)
and 2 (pageout); see
.IR init (8).
If
.I pid
is less than \-1,
it is negated
and taken as a process group
whose members should receive the signal.
.PP
Processes may send signals to themselves.
.SH FILES
.F core
.SH "SEE ALSO"
.IR kill (1),
.IR setjmp (3)
.SH DIAGNOSTICS
.IR signal :
.B EINVAL
.br
.IR kill :
.BR EINVAL ,
.BR EPERM ,
.BR ESRCH
.SH BUGS
Unadvertised and unsupported
.I func
and
.I sig
arguments can radically and permanently change the
behavior of signals.
.br
The reason for a trap should be distinguishable by extra arguments
to the signal handler.
.br
If a repeated signal arrives before the last one can be reset,
there is no chance to catch it.
.br
For historical reasons, the return value of
a catcher function is
.BR int ;
it is
.B void
in
.SM ANSI
standard C.
|
