Contents of /tags/mkinitrd-6_3_5/busybox/docs/ctty.htm
Parent Directory | Revision Log
Revision 1223 -
(show annotations)
(download)
(as text)
Sat Jan 29 14:06:54 2011 UTC (13 years, 8 months ago) by niro
File MIME type: text/html
File size: 17555 byte(s)
Sat Jan 29 14:06:54 2011 UTC (13 years, 8 months ago) by niro
File MIME type: text/html
File size: 17555 byte(s)
tagged 'mkinitrd-6_3_5'
1 | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> |
2 | <html><head> |
3 | <!-- saved from http://www.win.tue.nl/~aeb/linux/lk/lk-10.html --> |
4 | <meta name="GENERATOR" content="SGML-Tools 1.0.9"><title>The Linux kernel: Processes</title> |
5 | </head> |
6 | <body> |
7 | <hr> |
8 | <h2><a name="s10">10. Processes</a></h2> |
9 | |
10 | <p>Before looking at the Linux implementation, first a general Unix |
11 | description of threads, processes, process groups and sessions. |
12 | </p><p>A session contains a number of process groups, and a process group |
13 | contains a number of processes, and a process contains a number |
14 | of threads. |
15 | </p><p>A session can have a controlling tty. |
16 | At most one process group in a session can be a foreground process group. |
17 | An interrupt character typed on a tty ("Teletype", i.e., terminal) |
18 | causes a signal to be sent to all members of the foreground process group |
19 | in the session (if any) that has that tty as controlling tty. |
20 | </p><p>All these objects have numbers, and we have thread IDs, process IDs, |
21 | process group IDs and session IDs. |
22 | </p><p> |
23 | </p><h2><a name="ss10.1">10.1 Processes</a> |
24 | </h2> |
25 | |
26 | <p> |
27 | </p><h3>Creation</h3> |
28 | |
29 | <p>A new process is traditionally started using the <code>fork()</code> |
30 | system call: |
31 | </p><blockquote> |
32 | <pre>pid_t p; |
33 | |
34 | p = fork(); |
35 | if (p == (pid_t) -1) |
36 | /* ERROR */ |
37 | else if (p == 0) |
38 | /* CHILD */ |
39 | else |
40 | /* PARENT */ |
41 | </pre> |
42 | </blockquote> |
43 | <p>This creates a child as a duplicate of its parent. |
44 | Parent and child are identical in almost all respects. |
45 | In the code they are distinguished by the fact that the parent |
46 | learns the process ID of its child, while <code>fork()</code> |
47 | returns 0 in the child. (It can find the process ID of its |
48 | parent using the <code>getppid()</code> system call.) |
49 | </p><p> |
50 | </p><h3>Termination</h3> |
51 | |
52 | <p>Normal termination is when the process does |
53 | </p><blockquote> |
54 | <pre>exit(n); |
55 | </pre> |
56 | </blockquote> |
57 | |
58 | or |
59 | <blockquote> |
60 | <pre>return n; |
61 | </pre> |
62 | </blockquote> |
63 | |
64 | from its <code>main()</code> procedure. It returns the single byte <code>n</code> |
65 | to its parent. |
66 | <p>Abnormal termination is usually caused by a signal. |
67 | </p><p> |
68 | </p><h3>Collecting the exit code. Zombies</h3> |
69 | |
70 | <p>The parent does |
71 | </p><blockquote> |
72 | <pre>pid_t p; |
73 | int status; |
74 | |
75 | p = wait(&status); |
76 | </pre> |
77 | </blockquote> |
78 | |
79 | and collects two bytes: |
80 | <p> |
81 | <figure> |
82 | <eps file="absent"> |
83 | <img src="ctty_files/exit_status.png"> |
84 | </eps> |
85 | </figure></p><p>A process that has terminated but has not yet been waited for |
86 | is a <i>zombie</i>. It need only store these two bytes: |
87 | exit code and reason for termination. |
88 | </p><p>On the other hand, if the parent dies first, <code>init</code> (process 1) |
89 | inherits the child and becomes its parent. |
90 | </p><p> |
91 | </p><h3>Signals</h3> |
92 | |
93 | <p> |
94 | </p><h3>Stopping</h3> |
95 | |
96 | <p>Some signals cause a process to stop: |
97 | <code>SIGSTOP</code> (stop!), |
98 | <code>SIGTSTP</code> (stop from tty: probably ^Z was typed), |
99 | <code>SIGTTIN</code> (tty input asked by background process), |
100 | <code>SIGTTOU</code> (tty output sent by background process, and this was |
101 | disallowed by <code>stty tostop</code>). |
102 | </p><p>Apart from ^Z there also is ^Y. The former stops the process |
103 | when it is typed, the latter stops it when it is read. |
104 | </p><p>Signals generated by typing the corresponding character on some tty |
105 | are sent to all processes that are in the foreground process group |
106 | of the session that has that tty as controlling tty. (Details below.) |
107 | </p><p>If a process is being traced, every signal will stop it. |
108 | </p><p> |
109 | </p><h3>Continuing</h3> |
110 | |
111 | <p><code>SIGCONT</code>: continue a stopped process. |
112 | </p><p> |
113 | </p><h3>Terminating</h3> |
114 | |
115 | <p><code>SIGKILL</code> (die! now!), |
116 | <code>SIGTERM</code> (please, go away), |
117 | <code>SIGHUP</code> (modem hangup), |
118 | <code>SIGINT</code> (^C), |
119 | <code>SIGQUIT</code> (^\), etc. |
120 | Many signals have as default action to kill the target. |
121 | (Sometimes with an additional core dump, when such is |
122 | allowed by rlimit.) |
123 | The signals <code>SIGCHLD</code> and <code>SIGWINCH</code> |
124 | are ignored by default. |
125 | All except <code>SIGKILL</code> and <code>SIGSTOP</code> can be |
126 | caught or ignored or blocked. |
127 | For details, see <code>signal(7)</code>. |
128 | </p><p> |
129 | </p><h2><a name="ss10.2">10.2 Process groups</a> |
130 | </h2> |
131 | |
132 | <p>Every process is member of a unique <i>process group</i>, |
133 | identified by its <i>process group ID</i>. |
134 | (When the process is created, it becomes a member of the process group |
135 | of its parent.) |
136 | By convention, the process group ID of a process group |
137 | equals the process ID of the first member of the process group, |
138 | called the <i>process group leader</i>. |
139 | A process finds the ID of its process group using the system call |
140 | <code>getpgrp()</code>, or, equivalently, <code>getpgid(0)</code>. |
141 | One finds the process group ID of process <code>p</code> using |
142 | <code>getpgid(p)</code>. |
143 | </p><p>One may use the command <code>ps j</code> to see PPID (parent process ID), |
144 | PID (process ID), PGID (process group ID) and SID (session ID) |
145 | of processes. With a shell that does not know about job control, |
146 | like <code>ash</code>, each of its children will be in the same session |
147 | and have the same process group as the shell. With a shell that knows |
148 | about job control, like <code>bash</code>, the processes of one pipeline, like |
149 | </p><blockquote> |
150 | <pre>% cat paper | ideal | pic | tbl | eqn | ditroff > out |
151 | </pre> |
152 | </blockquote> |
153 | |
154 | form a single process group. |
155 | <p> |
156 | </p><h3>Creation</h3> |
157 | |
158 | <p>A process <code>pid</code> is put into the process group <code>pgid</code> by |
159 | </p><blockquote> |
160 | <pre>setpgid(pid, pgid); |
161 | </pre> |
162 | </blockquote> |
163 | |
164 | If <code>pgid == pid</code> or <code>pgid == 0</code> then this creates |
165 | a new process group with process group leader <code>pid</code>. |
166 | Otherwise, this puts <code>pid</code> into the already existing |
167 | process group <code>pgid</code>. |
168 | A zero <code>pid</code> refers to the current process. |
169 | The call <code>setpgrp()</code> is equivalent to <code>setpgid(0,0)</code>. |
170 | <p> |
171 | </p><h3>Restrictions on setpgid()</h3> |
172 | |
173 | <p>The calling process must be <code>pid</code> itself, or its parent, |
174 | and the parent can only do this before <code>pid</code> has done |
175 | <code>exec()</code>, and only when both belong to the same session. |
176 | It is an error if process <code>pid</code> is a session leader |
177 | (and this call would change its <code>pgid</code>). |
178 | </p><p> |
179 | </p><h3>Typical sequence</h3> |
180 | |
181 | <p> |
182 | </p><blockquote> |
183 | <pre>p = fork(); |
184 | if (p == (pid_t) -1) { |
185 | /* ERROR */ |
186 | } else if (p == 0) { /* CHILD */ |
187 | setpgid(0, pgid); |
188 | ... |
189 | } else { /* PARENT */ |
190 | setpgid(p, pgid); |
191 | ... |
192 | } |
193 | </pre> |
194 | </blockquote> |
195 | |
196 | This ensures that regardless of whether parent or child is scheduled |
197 | first, the process group setting is as expected by both. |
198 | <p> |
199 | </p><h3>Signalling and waiting</h3> |
200 | |
201 | <p>One can signal all members of a process group: |
202 | </p><blockquote> |
203 | <pre>killpg(pgrp, sig); |
204 | </pre> |
205 | </blockquote> |
206 | <p>One can wait for children in ones own process group: |
207 | </p><blockquote> |
208 | <pre>waitpid(0, &status, ...); |
209 | </pre> |
210 | </blockquote> |
211 | |
212 | or in a specified process group: |
213 | <blockquote> |
214 | <pre>waitpid(-pgrp, &status, ...); |
215 | </pre> |
216 | </blockquote> |
217 | <p> |
218 | </p><h3>Foreground process group</h3> |
219 | |
220 | <p>Among the process groups in a session at most one can be |
221 | the <i>foreground process group</i> of that session. |
222 | The tty input and tty signals (signals generated by ^C, ^Z, etc.) |
223 | go to processes in this foreground process group. |
224 | </p><p>A process can determine the foreground process group in its session |
225 | using <code>tcgetpgrp(fd)</code>, where <code>fd</code> refers to its |
226 | controlling tty. If there is none, this returns a random value |
227 | larger than 1 that is not a process group ID. |
228 | </p><p>A process can set the foreground process group in its session |
229 | using <code>tcsetpgrp(fd,pgrp)</code>, where <code>fd</code> refers to its |
230 | controlling tty, and <code>pgrp</code> is a process group in |
231 | its session, and this session still is associated to the controlling |
232 | tty of the calling process. |
233 | </p><p>How does one get <code>fd</code>? By definition, <code>/dev/tty</code> |
234 | refers to the controlling tty, entirely independent of redirects |
235 | of standard input and output. (There is also the function |
236 | <code>ctermid()</code> to get the name of the controlling terminal. |
237 | On a POSIX standard system it will return <code>/dev/tty</code>.) |
238 | Opening the name of the |
239 | controlling tty gives a file descriptor <code>fd</code>. |
240 | </p><p> |
241 | </p><h3>Background process groups</h3> |
242 | |
243 | <p>All process groups in a session that are not foreground |
244 | process group are <i>background process groups</i>. |
245 | Since the user at the keyboard is interacting with foreground |
246 | processes, background processes should stay away from it. |
247 | When a background process reads from the terminal it gets |
248 | a SIGTTIN signal. Normally, that will stop it, the job control shell |
249 | notices and tells the user, who can say <code>fg</code> to continue |
250 | this background process as a foreground process, and then this |
251 | process can read from the terminal. But if the background process |
252 | ignores or blocks the SIGTTIN signal, or if its process group |
253 | is orphaned (see below), then the read() returns an EIO error, |
254 | and no signal is sent. (Indeed, the idea is to tell the process |
255 | that reading from the terminal is not allowed right now. |
256 | If it wouldn't see the signal, then it will see the error return.) |
257 | </p><p>When a background process writes to the terminal, it may get |
258 | a SIGTTOU signal. May: namely, when the flag that this must happen |
259 | is set (it is off by default). One can set the flag by |
260 | </p><blockquote> |
261 | <pre>% stty tostop |
262 | </pre> |
263 | </blockquote> |
264 | |
265 | and clear it again by |
266 | <blockquote> |
267 | <pre>% stty -tostop |
268 | </pre> |
269 | </blockquote> |
270 | |
271 | and inspect it by |
272 | <blockquote> |
273 | <pre>% stty -a |
274 | </pre> |
275 | </blockquote> |
276 | |
277 | Again, if TOSTOP is set but the background process ignores or blocks |
278 | the SIGTTOU signal, or if its process group is orphaned (see below), |
279 | then the write() returns an EIO error, and no signal is sent. |
280 | <p> |
281 | </p><h3>Orphaned process groups</h3> |
282 | |
283 | <p>The process group leader is the first member of the process group. |
284 | It may terminate before the others, and then the process group is |
285 | without leader. |
286 | </p><p>A process group is called <i>orphaned</i> when <i>the |
287 | parent of every member is either in the process group |
288 | or outside the session</i>. |
289 | In particular, the process group of the session leader |
290 | is always orphaned. |
291 | </p><p>If termination of a process causes a process group to become |
292 | orphaned, and some member is stopped, then all are sent first SIGHUP |
293 | and then SIGCONT. |
294 | </p><p>The idea is that perhaps the parent of the process group leader |
295 | is a job control shell. (In the same session but a different |
296 | process group.) As long as this parent is alive, it can |
297 | handle the stopping and starting of members in the process group. |
298 | When it dies, there may be nobody to continue stopped processes. |
299 | Therefore, these stopped processes are sent SIGHUP, so that they |
300 | die unless they catch or ignore it, and then SIGCONT to continue them. |
301 | </p><p>Note that the process group of the session leader is already |
302 | orphaned, so no signals are sent when the session leader dies. |
303 | </p><p>Note also that a process group can become orphaned in two ways |
304 | by termination of a process: either it was a parent and not itself |
305 | in the process group, or it was the last element of the process group |
306 | with a parent outside but in the same session. |
307 | Furthermore, that a process group can become orphaned |
308 | other than by termination of a process, namely when some |
309 | member is moved to a different process group. |
310 | </p><p> |
311 | </p><h2><a name="ss10.3">10.3 Sessions</a> |
312 | </h2> |
313 | |
314 | <p>Every process group is in a unique <i>session</i>. |
315 | (When the process is created, it becomes a member of the session |
316 | of its parent.) |
317 | By convention, the session ID of a session |
318 | equals the process ID of the first member of the session, |
319 | called the <i>session leader</i>. |
320 | A process finds the ID of its session using the system call |
321 | <code>getsid()</code>. |
322 | </p><p>Every session may have a <i>controlling tty</i>, |
323 | that then also is called the controlling tty of each of |
324 | its member processes. |
325 | A file descriptor for the controlling tty is obtained by |
326 | opening <code>/dev/tty</code>. (And when that fails, there was no |
327 | controlling tty.) Given a file descriptor for the controlling tty, |
328 | one may obtain the SID using <code>tcgetsid(fd)</code>. |
329 | </p><p>A session is often set up by a login process. The terminal |
330 | on which one is logged in then becomes the controlling tty |
331 | of the session. All processes that are descendants of the |
332 | login process will in general be members of the session. |
333 | </p><p> |
334 | </p><h3>Creation</h3> |
335 | |
336 | <p>A new session is created by |
337 | </p><blockquote> |
338 | <pre>pid = setsid(); |
339 | </pre> |
340 | </blockquote> |
341 | |
342 | This is allowed only when the current process is not a process group leader. |
343 | In order to be sure of that we fork first: |
344 | <blockquote> |
345 | <pre>p = fork(); |
346 | if (p) exit(0); |
347 | pid = setsid(); |
348 | </pre> |
349 | </blockquote> |
350 | |
351 | The result is that the current process (with process ID <code>pid</code>) |
352 | becomes session leader of a new session with session ID <code>pid</code>. |
353 | Moreover, it becomes process group leader of a new process group. |
354 | Both session and process group contain only the single process <code>pid</code>. |
355 | Furthermore, this process has no controlling tty. |
356 | <p>The restriction that the current process must not be a process group leader |
357 | is needed: otherwise its PID serves as PGID of some existing process group |
358 | and cannot be used as the PGID of a new process group. |
359 | </p><p> |
360 | </p><h3>Getting a controlling tty</h3> |
361 | |
362 | <p>How does one get a controlling terminal? Nobody knows, |
363 | this is a great mystery. |
364 | </p><p>The System V approach is that the first tty opened by the process |
365 | becomes its controlling tty. |
366 | </p><p>The BSD approach is that one has to explicitly call |
367 | </p><blockquote> |
368 | <pre>ioctl(fd, TIOCSCTTY, 0/1); |
369 | </pre> |
370 | </blockquote> |
371 | |
372 | to get a controlling tty. |
373 | <p>Linux tries to be compatible with both, as always, and this |
374 | results in a very obscure complex of conditions. Roughly: |
375 | </p><p>The <code>TIOCSCTTY</code> ioctl will give us a controlling tty, |
376 | provided that (i) the current process is a session leader, |
377 | and (ii) it does not yet have a controlling tty, and |
378 | (iii) maybe the tty should not already control some other session; |
379 | if it does it is an error if we aren't root, or we steal the tty |
380 | if we are all-powerful. |
381 | [vda: correction: third parameter controls this: if 1, we steal tty from |
382 | any such session, if 0, we don't steal] |
383 | </p><p>Opening some terminal will give us a controlling tty, |
384 | provided that (i) the current process is a session leader, and |
385 | (ii) it does not yet have a controlling tty, and |
386 | (iii) the tty does not already control some other session, and |
387 | (iv) the open did not have the <code>O_NOCTTY</code> flag, and |
388 | (v) the tty is not the foreground VT, and |
389 | (vi) the tty is not the console, and |
390 | (vii) maybe the tty should not be master or slave pty. |
391 | </p><p> |
392 | </p><h3>Getting rid of a controlling tty</h3> |
393 | |
394 | <p>If a process wants to continue as a daemon, it must detach itself |
395 | from its controlling tty. Above we saw that <code>setsid()</code> |
396 | will remove the controlling tty. Also the ioctl TIOCNOTTY does this. |
397 | Moreover, in order not to get a controlling tty again as soon as it |
398 | opens a tty, the process has to fork once more, to assure that it |
399 | is not a session leader. Typical code fragment: |
400 | </p><p> |
401 | </p><pre> if ((fork()) != 0) |
402 | exit(0); |
403 | setsid(); |
404 | if ((fork()) != 0) |
405 | exit(0); |
406 | </pre> |
407 | <p>See also <code>daemon(3)</code>. |
408 | </p><p> |
409 | </p><h3>Disconnect</h3> |
410 | |
411 | <p>If the terminal goes away by modem hangup, and the line was not local, |
412 | then a SIGHUP is sent to the session leader. |
413 | Any further reads from the gone terminal return EOF. |
414 | (Or possibly -1 with <code>errno</code> set to EIO.) |
415 | </p><p>If the terminal is the slave side of a pseudotty, and the master side |
416 | is closed (for the last time), then a SIGHUP is sent to the foreground |
417 | process group of the slave side. |
418 | </p><p>When the session leader dies, a SIGHUP is sent to all processes |
419 | in the foreground process group. Moreover, the terminal stops being |
420 | the controlling terminal of this session (so that it can become |
421 | the controlling terminal of another session). |
422 | </p><p>Thus, if the terminal goes away and the session leader is |
423 | a job control shell, then it can handle things for its descendants, |
424 | e.g. by sending them again a SIGHUP. |
425 | If on the other hand the session leader is an innocent process |
426 | that does not catch SIGHUP, it will die, and all foreground processes |
427 | get a SIGHUP. |
428 | </p><p> |
429 | </p><h2><a name="ss10.4">10.4 Threads</a> |
430 | </h2> |
431 | |
432 | <p>A process can have several threads. New threads (with the same PID |
433 | as the parent thread) are started using the <code>clone</code> system |
434 | call using the <code>CLONE_THREAD</code> flag. Threads are distinguished |
435 | by a <i>thread ID</i> (TID). An ordinary process has a single thread |
436 | with TID equal to PID. The system call <code>gettid()</code> returns the |
437 | TID. The system call <code>tkill()</code> sends a signal to a single thread. |
438 | </p><p>Example: a process with two threads. Both only print PID and TID and exit. |
439 | (Linux 2.4.19 or later.) |
440 | </p><pre>% cat << EOF > gettid-demo.c |
441 | #include <unistd.h> |
442 | #include <sys/types.h> |
443 | #define CLONE_SIGHAND 0x00000800 |
444 | #define CLONE_THREAD 0x00010000 |
445 | #include <linux/unistd.h> |
446 | #include <errno.h> |
447 | _syscall0(pid_t,gettid) |
448 | |
449 | int thread(void *p) { |
450 | printf("thread: %d %d\n", gettid(), getpid()); |
451 | } |
452 | |
453 | main() { |
454 | unsigned char stack[4096]; |
455 | int i; |
456 | |
457 | i = clone(thread, stack+2048, CLONE_THREAD | CLONE_SIGHAND, NULL); |
458 | if (i == -1) |
459 | perror("clone"); |
460 | else |
461 | printf("clone returns %d\n", i); |
462 | printf("parent: %d %d\n", gettid(), getpid()); |
463 | } |
464 | EOF |
465 | % cc -o gettid-demo gettid-demo.c |
466 | % ./gettid-demo |
467 | clone returns 21826 |
468 | parent: 21825 21825 |
469 | thread: 21826 21825 |
470 | % |
471 | </pre> |
472 | <p> |
473 | </p><p> |
474 | </p><hr> |
475 | |
476 | </body></html> |