1POSIX and init: 2-------------- 3 4POSIX.1 does not define 'init' but it mentions it in a few places. 5 6B.2.2.2, p205 line 873: 7 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 -- 11 it sets SIGTSTP, SIGTTIN and SIGTTOU to SIG_IGN. 12 13B.2.2.2, p206 line 889: 14 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. 24 25B.2.2.2, p206 line 921: 26 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. 30 31B.2.2.2, p233 line 2055: 32 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.' 36 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. 46 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). 50 51On setsid(): 52----------- 53 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. 58 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. 64 65Controlling terminals: 66--------------------- 67 68B.7.1.1.3 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. 74 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). 79 80Design notes: 81------------ 82 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... 99 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 113