init man page on HP-UX

Man page or keyword search:  
man Server   10987 pages
apropos Keyword Search (all sections)
Output format
HP-UX logo
[printable version]

init(1M)							      init(1M)

       init - process control initialization

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

       At boot time, is started as a system daemon.

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

       The arguments have the following effect:

	      Place the system in one of the run levels

	      Process the
			entries	 that  have the special "run level" or without
			changing the numeric run level.

	      Re-examine the
			entries without changing the run level.

	      Enter the single-user environment.
			When this level change occurs, the logical system con‐
			sole is changed to the terminal from which the command
			was executed.

       Boot considers the system to be in a 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 for each of these run levels are defined in
       the file.  Boot can be in one of eight run levels, and or The run level
       is  changed  by	having	a privileged user run the command.  This user-
       spawned sends appropriate signals to the boot

       Boot is invoked inside the HP-UX system as the last step	 in  the  boot
       procedure.  Boot first performs any required machine-dependent initial‐
       ization, such as setting the system context.  Next, boot looks for  the
       file  to	 see if there is an entry of the type (see inittab(4)).	 If an
       entry is found, boot uses the run level specified in that entry as  the
       initial	run  level to enter.  If this entry is not in or is not found,
       boot requests that the user enter a run level from the  logical	system
       console,	 If or is entered, boot goes into the level.  This is the only
       run level that does not require the existence of a  properly  formatted
       file.  If does not exist, then by default the only legal run level that
       boot can enter is the single-user level.

       In the single-user level, the logical system console terminal is opened
       for reading and writing, and the command or is invoked immediately.  To
       exit from the  single-user  run	level,	one  of	 two  options  can  be

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

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

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

       When  boot prompts for the new run level, you can only enter one of the
       digits through or the letter or If you enter boot  operates  as	previ‐
       ously  described in single-user mode with the additional result that is
       linked to the user's terminal line, thus making it the  logical	system
       console.	  A message is generated on the physical system console, iden‐
       tifying the new logical system console.

       When boot 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, to those modes saved in the file This  file
       is  written by boot whenever single-user mode is entered.  If this file
       does not exist when boot wants to read it, a  warning  is  printed  and
       default settings are assumed.

       If  through  is	entered, boot enters the corresponding run level.  Any
       other input is rejected and a new prompt is issued.   If	 this  is  the
       first  time  boot  has entered a run level other than single-user, boot
       first scans for special entries of the type and These entries are  per‐
       formed  — provided that the run level entered matches that of the entry
       — before any normal processing of takes place.  In this way,  any  spe‐
       cial initialization of the operating system, such as mounting file sys‐
       tems, can take place before users are allowed  onto  the	 system.   The
       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:

	      Shut down HP-UX.

	      Use  for	system	administration	(also  known  as  "single-user
	      state"). When booting
			into run level at powerup, the only access to the sys‐
			tem 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 in the shell on the system console, and any  pro‐
			cesses	started	 by the system administrator. Adminis‐
			tration 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 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.

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

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

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

	      Activate graphical presentation managers and start other	system

	      These states are available for user-defined operations.

       The  default  run level is usually run level or depending on the system

       When transitions into a new run level the master	 sequencer  script  is
       invoked.	  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, and when transitioning
       to a lower run level kill scripts are invoked.  See rc(1M).

       In a multiuser environment, the file is usually set  up	so  that  boot
       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 hang‐
       ing  up.	  When	boot  receives	a child death signal telling it that a
       process it spawned has died, it records the fact and the reason it died
       in  the	database, and if it exist (see who(1)).	 A history of the pro‐
       cesses spawned is kept in and if it exists.

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

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

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

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

   Boot Authentication
       The system administrator can enable the	boot  authentication  feature.
       If enabled, the system cannot be booted into single user mode until the
       password of a user authorized to boot the system in single user mode is
       provided.   Refer  to  the  file	 in  the  security(4)  manual page for
       detailed information on configurable parameters that affect the	behav‐
       ior  of	this  command.	 The  currently	 supported parameters for boot
       authentication are:


       On systems that have been converted to trusted  mode,  use  the	System
       Administration Manager (SAM) program (see sam(1M)).

       If  boot	 finds	that  it is continuously respawning an entry from 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 This prevents boot from using up sys‐
       tem resources if there is a typographical error in the file or  a  pro‐
       gram is removed that is referenced in

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

       One particular scenario that often causes confusing behavior can	 occur
       when  a	child  or  is started by a login shell.	 When boot is asked to
       change to a run level that would cause the original login shell	to  be
       killed,	the  shell's  descendant  or 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
       cannot kill this or process (or any of its children).

       If a process is later started on the same tty as this  previous	shell,
       the result may be two processes (the and the job control shell) compet‐
       ing 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 is invoked from the lowest level (login)
       shell when changing to an init state that may cause your login shell to
       be killed.

       If is unable to write to a message is logged to the console.  This  may
       lead to the corruption of console settings.

       HP-UX  11i  Version  3  is  the last release to support trusted systems

       csh(1), ksh(1), login(1), sh(1), who(1), getty(1M), rc(1M),  utmpd(1M),
       ioctl(2),   kill(2),  setpgid(2),  setsid(2),  getutsent(3C),  updateb‐
       wdb(3C), inittab(4), security(4), utmp(4).


List of man pages available for HP-UX

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
Vote for polarhome
Free Shell Accounts :: the biggest list on the net