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