Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
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  se-

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

	  o  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 de-
       fault 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 re-
			pair 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 of-
			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  and if they exist (see who(1)).  A history of the processes spawned
       is kept in 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 re-
       sponse, 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.

       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.

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



Want to link to this manual page? Use this URL:

home | help