Museum

Home

Lab Overview

Retrotechnology Articles

⇒ Online Manual

Media Vault

Software Library

Restoration Projects

Artifacts Sought

Related Articles

boot(HW)

disable(C)

enable(C)

getty(M)

gettydefs(F)

initcond(ADM)

initscript(ADM)

inittab(F)

kill(S)

login(M)

sh(C)

shutdown(ADM)

stty(C)

sulogin(ADM)

termio(M)

utmp(F)

who(C)


 init(M)                       06 January 1993                        init(M)


 Name

    init, telinit - process control initialization

 Syntax

    /etc/init [ 0123456SsQqabc ]

    /bin/telinit [ 0123456SsQqabc ]

 Description

    init is a general process spawner.  Its primary role is to create pro-
    cesses from information stored in the file /etc/inittab (see inittab(F)
    for further details).

    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.

    If the file /etc/default/boot contains the string MAPKEY=YES, init
    invokes the mapkey program (see mapkey(M)) to map the console keyboard.
    If the call to mapkey succeeds, the console is set to 8-bits no parity.
    If the call fails, and the string SERIAL8=YES appears in
    /etc/default/boot, a serial console device is assumed and set to 8-bits
    no parity.  For additional information on keywords, see the ``Default
    file Settings'' section of boot(HW).

    The following are the arguments to init:

       0      shut the machine down so it is safe to remove the power.  Have
              the machine remove power if it can.  This state can be executed
              only from the console.

       1      put the system in single-user mode.  Unmount all file systems
              except root.  All user processes are killed except those con-
              nected to the console.  This state can be executed only from
              the console.

       2      put the system in multiuser mode.  All multiuser environment
              terminal processes and daemons are spawned.  This state is com-
              monly referred to as the multiuser state.

       3      start the remote file sharing processes and daemons.  Mount and
              advertise remote resources.  Run-level 3 extends multiuser mode
              and is known as the remote-file-sharing state.

       4      is available to be defined as an alternative multiuser environ-
              ment configuration.  It is not necessary for system operation
              and is usually not used.

       5      Stop the UNIX system and go to the firmware monitor.

       6      Stop the UNIX system and reboot to the state defined by the
              initdefault entry in /etc/inittab.

       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.

       S,s    enter single-user mode.  When this occurs, the terminal which
              executed this command becomes the system console (see ``Notes''
              for more information about console device assignment).  This is
              the only run-level that doesn't require the existence of a
              properly formatted /etc/inittab file.  If this file does not
              exist, then by default the only legal run-level that init can
              enter is the single-user mode.  When the system enters S or s,
              all mounted file systems remain mounted and only processes
              spawned by init are killed.

    When a UNIX system is booted, init is invoked and the following occurs.
    init first looks in /etc/default/boot to determine if autoboot on panic
    is desired.  init then looks to see if DEFAULT_LEVEL=n is specified in
    /etc/default/boot.  If it is, then n is the default level, otherwise, the
    user is prompted to see if they wish to go to multiuser or system mainte-
    nance mode (single-user mode).  In the single-user state, the virtual
    console terminal is assigned to the user's terminal and is opened for
    reading and writing.  The sulogin command, which requires the user to
    enter the root password, 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.
    Note that, on the 80386 computer, the run-levels 0, 1, 5, and 6 are
    reserved states for shutting the system down; the run-levels 2, 3, and 4
    are available as normal operating states.

    On your computer, the run-levels 0 and 1 are reserved states for shutting
    the system down, and run-levels 2, 3, and 4 are available as normal oper-
    ating states.

    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(F)).  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 spe-
    cial 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 multiuser environment, /etc/inittab is set up so that init will cre-
    ate 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.  init spawns
    each process by forking a shell to run the job in.  To set up the
    environment for this shell, init uses the /etc/initscript file which con-
    tains the definitions of some global variables, for example, TZ, HZ, and
    PATH.  (For more information about /etc/initscript, see initscript(ADM).)

    After init has spawned all of the processes specified by /etc/inittab, it
    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; how-
    ever, init still waits for one of the above three conditions to occur
    before re-examining /etc/inittab.  To get around this, an 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(S) 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.

    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(C)).  A history of the
    processes spawned is kept in /etc/wtmp.

    If init receives a ``powerfail'' signal (SIGPWR) it scans /etc/inittab
    for special entries of the type ``powerfail'' and ``powerwait''.  These
    entries are invoked (if the run-levels permit) before any further pro-
    cessing takes place.  In this way init can perform various cleanup and
    recording functions during the powerdown of the operating system.  Note
    that in the single-user states, S and s, only ``powerfail'' and
    ``powerwait'' entries are executed.  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.

 Files

    /etc/default/boot
    /etc/inittab
    /etc/utmp
    /etc/wtmp
    /etc/ioctl.syscon
    /etc/initscript
    /dev/console
    /dev/contty

 See also

    boot(HW), disable(C), enable(C), getty(M), gettydefs(F), initcond(ADM),
    initscript(ADM), inittab(F), kill(S), login(M), sh(C), shutdown(ADM),
    stty(C),
    sulogin(ADM), termio(M), utmp(F), who(C)

 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 com-
    mand 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 some-
    one 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.

 Notes

    init and telinit can be run only by someone who is super 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 assignment of the console device may seem confusing at first.  When-
    ever the system is rebooted, the first boot up messages will be displayed
    on the ``normal'' system console (tty01), then the prompt for going mul-
    tiuser will be displayed on the the tty from which init S was last
    invoked, which could be any tty on the system.  The system console device
    (/dev/syscon) remains linked to the tty from which the last init S is
    invoked. Rebooting the system does not reset this to tty01.

    If the /etc/initscript file is not present, init will print a warning on
    the console and spawn the job without setting up the global environment.

    The change to /etc/gettydefs described in the ``Notes'' section of the -
    gettydefs(F) manual page will permit terminals to pass 8 bits to the sys-
    tem as long as the system is in multiuser 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

    The /etc/TIMEZONE file should exist. /etc/initscript tries to execute
    this file to set the correct TZ variable for the system.

 Standards conformance

    init is conformant with:

    AT&T SVID Issue 2.


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