Museum

Home

Lab Overview

Retrotechnology Articles

Online Manuals

⇒ telinit(1m) — DG/UX 4.30

Media Vault

Software Library

Restoration Projects

Artifacts Sought

Related Articles

getty(1M)

shutdown(1M)

gettydefs(4)

inittab(4)

utmp(4)

termio(7)

login(1)

sh(1)

stty(1)

who(1)

telinit(1M)

kill(2)



     init(1m)                   DG/UX 4.30                    init(1m)



     NAME
          init, telinit - process control initialization

     SYNOPSIS
          /etc/init [0123456SsQqabc]

          /etc/telinit [0123456SsQqabc]

     DESCRIPTION
        Init
          init is a general process spawner.  Its primary role is to
          create processes from information stored in the file
          /etc/inittab (see inittab(4)).

          At any given time, the system is in one of eight possible
          run levels.  A run level is a software configuration of the
          system under which only a selected group of processes exist.
          The processes spawned by init for each of these run levels
          are defined in /etc/inittab.  init can be in one of eight
          run levels, 0-6 and S or s (run levels S and s are
          identical).  The run level changes when a privileged user
          runs /etc/init.  This user-spawned init sends appropriate
          signals to the original init spawned by the operating system
          when the system was booted, telling it which run level to
          change to.

          The following are the arguments to init.

          S         Single User
                    A single user run state that is a safe state to
                    which the system can always be booted, assuming
                    the root (/) filesystem is intact.  The root
                    filesystem is mounted, and the init and su
                    processes are running on the console.

          0         Halt
                    A shutdown state where the system is shut down so
                    it is safe to halt the processor(s).

          1         Admin
                    A limited user run state used for administrative
                    purposes without users on the system.  The / and
                    /usr filesystems are mounted, the update daemon is
                    running, and getty processes are spawned on the
                    console and administrative terminals.

          2         Multi-user, Network Connected
                    A multi-user run state which allows users to log
                    in and make use of all system services and some
                    network services.  The system is connected to the
                    network and can access other hosts, but this
                    system's network services are not available to



     Licensed material--property of copyright holder(s)         Page 1





     init(1m)                   DG/UX 4.30                    init(1m)



                    other hosts.  Besides the services made available
                    in run state 1, all local filesystems are mounted,
                    various system service daemons like cron, lp, and
                    acct are started, all user terminal getty
                    processes are spawned, the network transport layer
                    is started, and yp lookup services are started.

          3         Multi-user, Full Network
                    A multi-user run state that allows users to log in
                    and make full use of all system and network
                    services.  Besides the services made available in
                    run state 2, all network daemons and services are
                    started.  Remote mounted filesystems are mounted.

          4         Customer Defined
                    A multi-user run state to be defined as an
                    alternate site-specific environment by the
                    customer.  Not necessary for system operation.

          5,6       Not currently defined.

          a,b,c     process only those /etc/inittab entries having the
                    a, b or c run level set.  These are pseudo-states,
                    which may be defined to run certain commands, but
                    which do not cause the current run level to
                    change.

          Q,q       re-examine /etc/inittab.

          When a DG/UX system is booted, init is invoked and the
          following occurs.  First, init attempts to fsck and mount
          /usr using the /usr entry in /etc/fstab.  If there is no
          /etc/fstab but there is an /etc/fstab.proto, init copies
          /etc/fstab.proto to /etc/fstab and then attempts the mount
          operation.  The sequence is equivalent to:

          if   [ ! -f /etc/fstab ] &&
               [ -f /etc/fstab.proto ]
          then
               cp /etc/fstab.proto /etc/fstab
          fi
          mount -f /
          fsck -xq /usr
          mount /usr

          Next, init looks in /etc/inittab for the initdefault entry
          (see inittab(4)).  If there is one, init uses the run level
          specified in that entry as the initial run level to enter.
          If there is no initdefault entry in /etc/inittab, init
          requests that the user enter a run level from the virtual
          system console.  If an S or s is entered, init goes to the
          single-user state.  If /usr was not mounted successfully,



     Licensed material--property of copyright holder(s)         Page 2





     init(1m)                   DG/UX 4.30                    init(1m)



          then single-user state is entered regardless of the
          initdefault setting in inittab.  In the single-user state
          the virtual console terminal is assigned to the user's
          terminal and is opened for reading and writing.  The command
          /bin/su is invoked and a message is generated on the
          physical console saying where the virtual console has been
          relocated.  Use either init or telinit, to signal init to
          change the run level of the system.  Note that if the shell
          is terminated (via an end-of-file), init will only re-
          initialize to the single-user state if the /etc/inittab file
          does not exist.

          If a 0 through 6 is entered, init enters the corresponding
          run level if /usr is mounted.  init will not permit a state
          change if /usr is not mounted.

          If this is the first time since power up that init has
          entered a run level other than single-user state, init first
          scans /etc/inittab for boot and bootwait entries (see
          inittab(4)).  These entries are performed before any other
          processing of /etc/inittab takes place, providing that the
          run level entered matches that of the entry.  In this way
          any special initialization of the operating system, such as
          mounting file systems, can take place before users are
          allowed onto the system.  init then scans /etc/inittab and
          executes all other entries that are to be processed for that
          run level.

          In a multi-user environment, /etc/inittab is set up so that
          init will create a getty process for each terminal that the
          administrator sets up to respawn.

          To spawn each process in /etc/inittab, init reads each entry
          and for each entry that should be respawned, it forks a
          child process.  After it has spawned all of the processes
          specified by /etc/inittab, init waits for one of its
          descendant processes to die, a powerfail signal, or a signal
          from another init or telinit process to change the system's
          run level.  When one of these conditions occurs, init re-
          examines /etc/inittab.  New entries can be added to
          /etc/inittab at any time; however, init still waits for one
          of the above three conditions to occur before re-examining
          /etc/inittab.  To get around this, init Q or init q command
          wakes init to re-examine /etc/inittab immediately.

          When init comes up at boot time and whenever the system
          changes from the single-user state to another run state,
          init sets the ioctl(2) states of the virtual console to
          those modes saved in the file /etc/ioctl.syscon.  This file
          is written by init whenever the single-user state is
          entered.




     Licensed material--property of copyright holder(s)         Page 3





     init(1m)                   DG/UX 4.30                    init(1m)



          When a run level change request is made init sends the
          warning signal (SIGTERM) to all processes that are undefined
          in the target run level.  init waits 5 seconds before
          forcibly terminating these processes via the kill signal
          (SIGKILL).

          The shell running on each terminal will terminate when the
          user types an end-of-file or hangs up.  When init receives a
          signal telling it that a process it spawned has died, it
          records the fact and the reason it died in /etc/utmp and
          /etc/wtmp if it exists (see who(1)).  A history of the
          processes spawned is kept in /etc/wtmp.

        telinit
          telinit, which is linked to /etc/init, is used to direct the
          actions of init.  It takes a one-character argument and
          signals init to take the appropriate action.  telinit is the
          AT&T version of BSD's init.

     FILES
          /etc/inittab
          /etc/utmp
          /etc/wtmp
          /etc/ioctl.syscon
          /dev/console
          /dev/contty

     SEE ALSO
          getty(1M), shutdown(1M), gettydefs(4), inittab(4), utmp(4),
          termio(7).
          login(1), sh(1), stty(1), who(1) telinit(1M)
          kill(2)

     DIAGNOSTICS
          If init finds that it is respawning an entry from
          /etc/inittab more than 10 times in 2 minutes, it will assume
          that there is an error in the command string in the entry,
          and generate an error message on the system console.  It
          will then refuse to respawn this entry until either 5
          minutes has elapsed or it receives a signal from a user-
          spawned init (telinit).  This prevents init from eating up
          system resources when someone makes a typographical error in
          the inittab file or a program is removed that is referenced
          in /etc/inittab.

          When attempting to boot the system, failure of init to
          prompt for a new run level may be because the virtual system
          console is linked to a device other than the physical system
          console.

     WARNINGS
          init and telinit can be run only by someone who is super-



     Licensed material--property of copyright holder(s)         Page 4





     init(1m)                   DG/UX 4.30                    init(1m)



          user.

          The S or s state must not be used indiscriminately in the
          /etc/inittab file.  A good rule to follow when modifying
          this file is to avoid adding this state to any line other
          than the initdefault.

          The change to /etc/gettydefs described in the WARNINGS
          section of the gettydefs(4) manual page will permit
          terminals to pass 8 bits to the system as long as the system
          is in multi-user state (run level greater than 1).  When the
          system changes to single-user state, the getty is killed and
          the terminal attributes are lost.  To permit a terminal to
          pass 8 bits to the system in single-user state, after you
          are in single-user state, type: stty -istrip cs8 .








































     Licensed material--property of copyright holder(s)         Page 5



Typewritten Software • bear@typewritten.org • Edmonds, WA 98026