sbin/init/NOTES

   1 $NetBSD: NOTES,v 1.3 2006/04/18 11:40:26 salo Exp $
   2
   3 POSIX and init:
   4 --------------
   5
   6 POSIX.1 does not define 'init' but it mentions it in a few places.
   7
   8 B.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
  15 B.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
  27 B.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
  33 B.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
  53 On setsid():
  54 -----------
  55
  56 It appears that neither getty nor login call setsid(), so init must
  57 do this -- seems reasonable.  B.4.3.2 p 248 implies that this is the
  58 way that 'init' should work; it says that setsid() should be called
  59 after forking.
  60
  61 Process group leaders cannot call setsid() -- another reason to
  62 fork!  Of course setsid() causes the current process to become a
  63 process group leader, so we can only call setsid() once.  Note that
  64 the controlling terminal acquires the session leader's process
  65 group when opened.
  66
  67 Controlling terminals:
  68 ---------------------
  69
  70 B.7.1.1.3 p276: 'POSIX.1 does not specify a mechanism by which to
  71 allocate a controlling terminal.  This is normally done by a system
  72 utility (such as 'getty') and is considered ... outside the scope
  73 of POSIX.1.'  It goes on to say that historically the first open()
  74 of a tty in a session sets the controlling terminal.  P130 has the
  75 full details; nothing particularly surprising.
  76
  77 The glossary p12 describes a 'controlling process' as the first
  78 process in a session that acquires a controlling terminal.  Access
  79 to the terminal from the session is revoked if the controlling
  80 process exits (see p50, in the discussion of process termination).
  81
  82 Design notes:
  83 ------------
  84
  85 your generic finite state machine
  86 we are fascist about which signals we elect to receive,
  87         even signals purportedly generated by hardware
  88 handle 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 :-)
  92 apply hysteresis to rapidly exiting gettys
  93 check wait status of children we reap
  94         don't wait for stopped children
  95 don't use SIGCHILD, it's too expensive
  96         but it may close windows and avoid races, sigh
  97 look for EINTR in case we need to change state
  98 init 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
 102 necessary 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)
 119 Given the -s flag, we start at state 1; otherwise state 2