GC !__DragonFly__ section.
[dragonfly.git] / sbin / init / NOTES
1POSIX and init:
4POSIX.1 does not define 'init' but it mentions it in a few places.
6B.2.2.2, p205 line 873:
8 This is part of the extensive 'job control' glossary entry.
9 This specific reference says that 'init' must by default provide
10 protection from job control signals to jobs it starts --
13B.2.2.2, p206 line 889:
15 Here is a reference to 'vhangup'. It says, 'POSIX.1 does
16 not specify how controlling terminal access is affected by
17 a user logging out (that is, by a controlling process
18 terminating).' vhangup() is recognized as one way to handle
19 the problem. I'm not clear what happens in Reno; I have
20 the impression that when the controlling process terminates,
21 references to the controlling terminal are converted to
22 references to a 'dead' vnode. I don't know whether vhangup()
23 is required.
25B.2.2.2, p206 line 921:
27 Orphaned process groups bear indirectly on this issue. A
28 session leader's process group is considered to be orphaned;
29 that is, it's immune to job control signals from the terminal.
31B.2.2.2, p233 line 2055:
33 'Historically, the implementation-dependent process that
34 inherits children whose parents have terminated without
35 waiting on them is called "init" and has a process ID of 1.'
37 It goes on to note that it used to be the case that 'init'
38 was responsible for sending SIGHUP to the foreground process
39 group of a tty whose controlling process has exited, using
40 vhangup(). It is now the responsibility of the kernel to
41 do this when the controlling process calls _exit(). The
42 kernel is also responsible for sending SIGCONT to stopped
43 process groups that become orphaned. This is like old BSD
44 but entire process groups are signaled instead of individual
45 processes.
47 In general it appears that the kernel now automatically
48 takes care of orphans, relieving 'init' of any responsibility.
49 Specifics are listed on the _exit() page (p50).
51On setsid():
54It appears that neither getty nor login call setsid(), so init must
55do this -- seems reasonable. B.4.3.2 p 248 implies that this is the
56way that 'init' should work; it says that setsid() should be called
57after forking.
59Process group leaders cannot call setsid() -- another reason to
60fork! Of course setsid() causes the current process to become a
61process group leader, so we can only call setsid() once. Note that
62the controlling terminal acquires the session leader's process
63group when opened.
65Controlling terminals:
68B. p276: 'POSIX.1 does not specify a mechanism by which to
69allocate a controlling terminal. This is normally done by a system
70utility (such as 'getty') and is considered ... outside the scope
71of POSIX.1.' It goes on to say that historically the first open()
72of a tty in a session sets the controlling terminal. P130 has the
73full details; nothing particularly surprising.
75The glossary p12 describes a 'controlling process' as the first
76process in a session that acquires a controlling terminal. Access
77to the terminal from the session is revoked if the controlling
78process exits (see p50, in the discussion of process termination).
80Design notes:
83your generic finite state machine
84we are fascist about which signals we elect to receive,
85 even signals purportedly generated by hardware
86handle fatal errors gracefully if possible (we reboot if we goof!!)
87 if we get a segmentation fault etc., print a message on the console
88 and spin for a while before rebooting
89 (this at least decreases the amount of paper consumed :-)
90apply hysteresis to rapidly exiting gettys
91check wait status of children we reap
92 don't wait for stopped children
93don't use SIGCHILD, it's too expensive
94 but it may close windows and avoid races, sigh
95look for EINTR in case we need to change state
96init is responsible for utmp and wtmp maintenance (ick)
97 maybe now we can consider replacements? maintain them in parallel
98 init only removes utmp and closes out wtmp entries...
100necessary states and state transitions (gleaned from the man page):
101 1: single user shell (with password checking?); on exit, go to 2
102 2: rc script: on exit 0, go to 3; on exit N (error), go to 1
103 3: read ttys file: on completion, go to 4
104 4: multi-user operation: on SIGTERM, go to 7; on SIGHUP, go to 5;
105 on SIGTSTP, go to 6
106 5: clean up mode (re-read ttys file, killing off controlling processes
107 on lines that are now 'off', starting them on lines newly 'on')
108 on completion, go to 4
109 6: boring mode (no new sessions); signals as in 4
110 7: death: send SIGHUP to all controlling processes, reap for 30 seconds,
111 then go to 1 (warn if not all processes died, i.e. wait blocks)
112Given the -s flag, we start at state 1; otherwise state 2