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

FreeBSD Manual Pages


home | help
INIT(8)			  BSD System Manager's Manual		       INIT(8)

     init -- process control initialization


     The init program is the last stage	of the boot process (after the kernel
     loads and initializes all the devices).  It normally begins multi-user

     The following table describes the state machine used by init:

     1.	  Single user shell.  init may be passed -s from the boot program to
	  prevent the system from going	multi-user and to instead execute a
	  single user shell without starting the normal	daemons.  If the ker-
	  nel is in a secure mode, init	will downgrade it to securelevel 0
	  (insecure mode).  The	system is then quiescent for maintenance work
	  and may later	be made	to go to state 2 (multi-user) by exiting the
	  single-user shell (with ^D).

     2.	  Multi-user boot (default operation).	Executes /etc/rc (see rc(8)).
	  If this was the first	state entered (as opposed to entering here af-
	  ter state 1),	then /etc/rc will be invoked with its first argument
	  being	`autoboot'.  If	/etc/rc	exits with a non-zero (error) exit
	  code,	commence single	user operation by giving the super-user	a
	  shell	on the console by going	to state 1 (single user).  Otherwise,
	  proceed to state 3.

	  If value of the "init.root" sysctl node is not equal to / at this
	  point, the /etc/rc process will be run inside	a chroot(2) indicated
	  by sysctl with the same error	handling as above.

	  If the administrator has not set the security	level to -1 to indi-
	  cate that the	kernel should not run multiuser	in secure mode,	and
	  the /etc/rc script has not set a higher level	of security than level
	  1, then init will put	the kernel into	securelevel mode 1.  See
	  rc.conf(5) and secmodel_securelevel(9) for more information.

     3.	  Set up ttys as specified in ttys(5).	See below for more informa-
	  tion.	 On completion,	continue to state 4.  If we did	chroot in
	  state	2, each	getty(8) process will be run in	the same chroot(2)
	  path as in 2 (that is, the value of "init.root" sysctl is not	re-

     4.	  Multi-user operation.	 Depending upon	the signal received, change
	  state	appropriately; on SIGTERM, go to state 7; on SIGHUP, go	to
	  state	5; on SIGTSTP, go to state 6.

     5.	  Clean-up mode; re-read ttys(5), killing off the controlling pro-
	  cesses on lines that are now `off', and starting processes that are
	  newly	`on'.  On completion, go to state 4.

     6.	  `Boring' mode; no new	sessions.  Signals as per state	4.

     7.	  Shutdown mode.  Send SIGHUP to all controlling processes, reap the
	  processes for	30 seconds, and	then go	to state 1 (single user);
	  warning if not all the processes died.

     If	the `console' entry in the ttys(5) file	is marked "insecure", then
     init will require that the	superuser password be entered before the sys-
     tem will start a single-user shell.  The password check is	skipped	if the
     `console' is marked as "secure".

     It	should be noted	that while init	has the	ability	to start multi-user
     operation inside a	chroot(2) environment, the init	process	itself will
     always run	in the "original root directory".  This	also implies that sin-
     gle-user mode is always started in	the original root, giving the possi-
     bility to create multi-user sessions in different root directories	over
     time.  The	"init.root" sysctl node	is fabricated by init at startup and
     re-created	any time it's found to be missing.  Type of the	node is	string
     capable of	holding	full pathname, and is only accessible by the superuser
     (unless explicitly	destroyed and re-created with different	specifica-

     In	multi-user operation, init maintains processes for the terminal	ports
     found in the file ttys(5).	 init reads this file, and executes the	com-
     mand found	in the second field.  This command is usually getty(8);	it
     opens and initializes the tty line	and executes the login(1) program.
     The login(1) program, when	a valid	user logs in, executes a shell for
     that user.	 When this shell dies, either because the user logged out or
     an	abnormal termination occurred (a signal), the init program wakes up,
     deletes the user from the utmp(5) and utmpx(5) files of current users and
     records the logout	in the wtmp(5) and wtmpx(5) files.  The	cycle is then
     restarted by init executing a new getty(8)	for the	line.

     Line status (on, off, secure, getty, or window information) may be
     changed in	the ttys(5) file without a reboot by sending the signal	SIGHUP
     to	init with the command "kill -s HUP 1".	This is	referenced in the ta-
     ble above as state	5.  On receipt of this signal, init re-reads the
     ttys(5) file.  When a line	is turned off in ttys(5), init will send a
     SIGHUP signal to the controlling process for the session associated with
     the line.	For any	lines that were	previously turned off in the ttys(5)
     file and are now on, init executes	a new getty(8) to enable a new login.
     If	the getty or window field for a	line is	changed, the change takes ef-
     fect at the end of	the current login session (e.g., the next time init
     starts a process on the line).  If	a line is commented out	or deleted
     from ttys(5), init	will not do anything at	all to that line.  However, it
     will complain that	the relationship between lines in the ttys(5) file and
     records in	the utmp(5) file is out	of sync, so this practice is not rec-

     init will terminate multi-user operations and resume single-user mode if
     sent a terminate (TERM) signal, for example, "kill	-s TERM	1".  If	there
     are processes outstanding that are	deadlocked (because of hardware	or
     software failure),	init will not wait for them all	to die (which might
     take forever), but	will time out after 30 seconds and print a warning

     init will cease creating new getty(8)'s and allow the system to slowly
     die away, if it is	sent a terminal	stop (TSTP) signal, i.e.  "kill	-s
     TSTP 1".  A later hangup will resume full multi-user operations, or a
     terminate will start a single user	shell.	This hook is used by reboot(8)
     and halt(8).

     The role of init is so critical that if it	dies, the system will reboot
     itself automatically.  If,	at bootstrap time, the init process cannot be
     located, or exits during its initialisation, the system will panic	with
     the message "panic: init died (signal %d, exit %d)".

     If	/dev/console does not exist, init will cd to /dev and run "MAKEDEV -MM
     init".  MAKEDEV(8)	will use mount_tmpfs(8)	or mount_mfs(8)	to create a
     memory file system	mounted	over /dev that contains	the standard devices
     considered	necessary to boot the system.

     /dev/console	System console device.
     /dev/tty*		Terminal ports found in	ttys(5).
     /var/run/utmp{,x}	Record of current users	on the system.
     /var/log/wtmp{,x}	Record of all logins and logouts.
     /etc/ttys		The terminal initialization information	file.
     /etc/rc		System startup commands.

     getty repeating too quickly on port %s, sleeping  A process being started
     to	service	a line is exiting quickly each time it is started.  This is
     often caused by a ringing or noisy	terminal line.	Init will sleep	for 10
     seconds, then continue trying to start the	process.

     some processes would not die; ps axl advised.  A process is hung and
     could not be killed when the system was shutting down.  This condition is
     usually caused by a process that is stuck in a device driver because of a
     persistent	device error condition.

     config(1),	kill(1), login(1), sh(1), options(4), ttys(5), getty(8),
     halt(8), MAKEDEV(8), MAKEDEV.local(8), mount_mfs(8), mount_tmpfs(8),
     rc(8), reboot(8), rescue(8), shutdown(8), sysctl(8), secmodel_bsd44(9),

     A init command appeared in	Version	6 AT&T UNIX.

BSD			       November	10, 2008			   BSD


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

home | help