Switch to SpeakEasy.net DSL

The Modular Manual Browser

Home Page
Manual: (HP-UX-11.11)
Apropos / Subsearch:
optional field

 init(1M)							    init(1M)

      init - process control initialization

      /sbin/init [0|1|2|3|4|5|6|S|s|Q|q|a|b|c]

      The init daemon and command is a general process spawner.	 Its primary
      role is to create processes from a script stored in the file
      /etc/inittab (see inittab(4)).  This file usually has init spawn a
      getty on each line where users can log in.  It also controls
      autonomous processes required by any particular system.

      At boot time, init is started as a system daemon.

      While the system is running, a user-spawned init directs the actions
      of the boot init.	 It accepts a one-character argument and signals the
      boot init with the kill() system call to perform the appropriate

      The arguments have the following effect:

	   0-6	     Place the system in one of the run levels 0 through 6.

	   a|b|c     Process the inittab entries that have the special "run
		     level" a, b, or c, without changing the numeric run

	   Q|q	     Re-examine the inittab entries without changing the run

	   S|s	     Enter the single-user environment.	 When this level
		     change occurs, the logical system console /dev/syscon
		     is changed to the terminal from which the command was

      Boot init considers the system to be in a run level at any given time.
      A run level can be viewed as a software configuration of the system,
      where each configuration allows only a selected group of processes to
      exist.  The processes spawned by boot init for each of these run
      levels are defined in the inittab file.  Boot init can be in one of
      eight run levels, 0-6, and S or s.  The run level is changed by having
      a privileged user run the init command.  This user-spawned init sends
      appropriate signals to the boot init.

      Boot init is invoked inside the HP-UX system as the last step in the
      boot procedure.  Boot init first performs any required machine-
      dependent initialization, such as setting the system context.  Next,
      boot init looks for the inittab file to see if there is an entry of
      the type initdefault (see inittab(4)).  If an initdefault entry is
      found, boot init uses the run level specified in that entry as the

 Hewlett-Packard Company	    - 1 -   HP-UX Release 11i: November 2000

 init(1M)							    init(1M)

      initial run level to enter.  If this entry is not in inittab, or
      inittab is not found, boot init requests that the user enter a run
      level from the logical system console, /dev/syscon.  If S or s is
      entered, boot init goes into the single-user level.  This is the only
      run level that does not require the existence of a properly formatted
      inittab file.  If inittab does not exist, then by default the only
      legal run level that boot init can enter is the single-user level.

      In the single-user level, the logical system console terminal
      /dev/syscon is opened for reading and writing, and the command
      /usr/bin/su, /usr/bin/sh, or /sbin/sh is invoked immediately.  To exit
      from the single-user run level, one of two options can be selected:

	 +  If the shell is terminated with an end-of-file, boot init
	    reprompts for a new run level.

	 +  User init can signal boot init and force it to change the
	    current system run level.

      When attempting to boot the system, some processes spawned by boot
      init may send display messages to the system console (depending on the
      contents of inittab).  If messages are expected but do not appear
      during booting, it may be caused by the logical system console
      (/dev/syscon) being linked to a device that is not the physical system
      console (/dev/systty).  If this occurs, you can force boot init to
      relink /dev/syscon to /dev/systty by pressing the DEL (delete) key
      (ASCII 127) on the physical system console.

      When boot init prompts for the new run level, you can only enter one
      of the digits 0 through 6 or the letter S or s.  If you enter S, boot
      init operates as previously described in single-user mode with the
      additional result that /dev/syscon is linked to the user's terminal
      line, thus making it the logical system console.	A message is
      generated on the physical system console, /dev/systty, identifying the
      new logical system console.

      When boot init comes up initially, and whenever it switches out of
      single-user state to normal run states, it sets the states (see
      ioctl(2)) of the logical system console, /dev/syscon, to those modes
      saved in the file /etc/ioctl.syscon.  This file is written by boot
      init whenever single-user mode is entered.  If this file does not
      exist when boot init wants to read it, a warning is printed and
      default settings are assumed.

      If 0 through 6 is entered, boot init enters the corresponding run
      level.  Any other input is rejected and a new prompt is issued.  If
      this is the first time boot init has entered a run level other than
      single-user, boot init first scans inittab for special entries of the
      type boot and bootwait.  These entries are performed - provided that
      the run level entered matches that of the entry - before any normal
      processing of inittab takes place.  In this way, any special

 Hewlett-Packard Company	    - 2 -   HP-UX Release 11i: November 2000

 init(1M)							    init(1M)

      initialization of the operating system, such as mounting file systems,
      can take place before users are allowed onto the system.	The inittab
      file is scanned to find all entries that are to be processed for that
      run level.

      Run levels in HP-UX are defined as follows:

	   0	     Shut down HP-UX.

	   S|s	     Use for system administration (also known as "single-
		     user state"). When booting into run level S at powerup,
		     the only access to the system is through a shell
		     spawned at the system console as the root user. The
		     only processes running on the system will be kernel
		     daemons started directly by the HP-UX kernel, daemon
		     processes started from entries of type sysinit in
		     /etc/inittab, the shell on the system console, and any
		     processes started by the system administrator.
		     Administration operations that require the system to be
		     in a quiescent state (such as the fsck(1M) operation to
		     repair a file system) should be run in this state.
		     Transitioning into run level S from a higher run level
		     does not terminate other system activity and does not
		     result in a "single-user state"; this operation should
		     not be done.

	   1	     Start a subset of essential system processes.  This
		     state can also be used to perform system administration

	   2	     Start most system daemons and login processes. This
		     state is often called the "multi-user state". Login
		     processes either at local terminals or over the network
		     are possible.

	   3	     Export filesystems and start other system processes. In
		     this state NFS filesystems are often exported, as may
		     be required for an NFS server.

	   4	     Activate graphical presentation managers and start
		     other system processes.

	   5-6	     These states are available for user-defined operations.

      The default run level is usually run level 3 or 4, depending on the
      system configuration.

      When init transitions into a new run level 0-6, the master sequencer
      script rc is invoked.  rc in turn invokes each of the start or kill
      scripts for each installed subsystem for each intervening run level.
      When transitioning to a higher run level start scripts are invoked,

 Hewlett-Packard Company	    - 3 -   HP-UX Release 11i: November 2000

 init(1M)							    init(1M)

      and when transitioning to a lower run level kill scripts are invoked.
      See rc(1M).

      In a multiuser environment, the inittab file is usually set up so that
      boot init creates a process for each terminal on the system.

      For terminal processes, ultimately the shell terminates because of an
      end-of-file either typed explicitly or generated as the result of
      hanging up.  When boot init receives a child death signal telling it
      that a process it spawned has died, it records the fact and the reason
      it died in /etc/utmp and /var/adm/wtmp, if they exist (see who(1)).  A
      history of the processes spawned is kept in /var/adm/wtmp, if it

      To spawn each process in the inittab file, boot 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 the
      inittab file, boot init waits for one of its descendant processes to
      die, a powerfail signal, or until it is signaled by a user init to
      change the system's run level.  When one of the above three conditions
      occurs, boot init re-examines the inittab file.  New entries can be
      added to the inittab file at any time.  However, boot init still waits
      for one of the above three conditions to occur.  For an instantaneous
      response, use the init Q (or init q) command to wake up boot init to
      re-examine the inittab file without changing the run level.

      If boot init receives a powerfail signal (SIGPWR) and is not in
      single-user mode, it scans inittab for special powerfail entries.
      These entries are invoked (if the run levels permit) before any other
      processing takes place by boot init.  In this way, boot init can
      perform various cleanup and recording functions whenever the operating
      system experiences a power failure.  Note, however, that although boot
      init receives SIGPWR immediately after a power failure, boot init
      cannot handle the signal until it resumes execution.  Since execution
      order is based on scheduling priority, any eligible process with a
      higher priority executes before boot init can scan inittab and perform
      the specified functions.

      When boot init is requested to change run levels via a user init, it
      sends the warning signal SIGTERM to all processes that are undefined
      in the target run level.	Boot init waits 20 seconds before forcibly
      terminating these processes with the kill signal SIGKILL.	 Note that
      boot init assumes that all these processes (and their descendants)
      remain in the same process group that boot init originally created for
      them.  If any process changes its process group affiliation with
      either setpgrp() or setpgrp2() (see setsid(2) and setpgid(2)), it will
      not receive these signals.  (Common examples of such processes are the
      shells csh and ksh (see csh(1) and ksh(1).) Such processes need to be
      terminated separately.

 Hewlett-Packard Company	    - 4 -   HP-UX Release 11i: November 2000

 init(1M)							    init(1M)

      A user init can be invoked only by users with appropriate privileges.

      If boot init finds that it is continuously respawning an entry from
      inittab more than 10 times in 2 minutes, it will assume that there is
      an error in the command string, generate an error message on the
      system console, and refuse to respawn this entry until either 5
      minutes have elapsed or it receives a signal from a user init.  This
      prevents boot init from using up system resources if there is a
      typographical error in the inittab file or a program is removed that
      is referenced in inittab.

      Boot init assumes that processes and descendants of processes spawned
      by boot init remain in the same process group that boot init
      originally created for them.  When changing init states, special care
      should be taken with processes that change their process group
      affiliation, such as csh and ksh.

      One particular scenario that often causes confusing behavior can occur
      when a child csh or ksh is started by a login shell.  When boot init
      is asked to change to a run level that would cause the original login
      shell to be killed, the shell's descendant csh or ksh process does not
      receive a hangup signal since it has changed its process group
      affiliation and is no longer affiliated with the process group of the
      original shell.  Boot init cannot kill this csh or ksh process (or any
      of its children).

      If a getty process is later started on the same tty as this previous
      shell, the result may be two processes (the getty and the job control
      shell) competing for input on the tty.

      To avoid problems such as this, always be sure to manually kill any
      job control shells that should not be running after changing init
      states.  Also, always be sure that user init is invoked from the
      lowest level (login) shell when changing to an init state that may
      cause your login shell to be killed.


      csh(1), ksh(1), login(1), sh(1), who(1), getty(1M), rc(1M), ioctl(2),
      kill(2), setpgid(2), setsid(2), inittab(4), security(4), utmp(4).

 Hewlett-Packard Company	    - 5 -   HP-UX Release 11i: November 2000

 init(1M)							    init(1M)

      init: SVID2, SVID3

 Hewlett-Packard Company	    - 6 -   HP-UX Release 11i: November 2000