*nix Documentation Project
·  Home
 +   man pages
·  Linux HOWTOs
·  FreeBSD Tips
·  *niX Forums

  man pages->IRIX man pages -> init (1)              


init(1M)							      init(1M)

NAME    [Toc]    [Back]

     init, telinit - process control initialization

SYNOPSIS    [Toc]    [Back]

     /etc/init [0123456SsQqabc]
     /etc/telinit [0123456SsQqabc]

DESCRIPTION    [Toc]    [Back]

     init is a general process spawner.	 Its primary role is to	create
     processes from information	stored in an inittab file (see inittab(4)).
     The default inittab file used is /etc/inittab; other files	can be
     specified using the INITTAB keyword in the	system file (see system(4)).

     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 is defined in 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-level
     init sends	appropriate signals to the original init (the one spawned by
     the operating system when the system was booted) designating the run
     level to which the	latter should change.

     The following are the arguments to	init.

     0	    Shut the machine down so it	is safe	to remove the power.  If it
	    can, the machine will remove the power provided the	kernel power
	    removal flag was previously	set (as	by the command /sbin/uadmin
	    256	9).

     1	    Put	the system into	system administrator mode.  All	filesystems
	    are	mounted.  Only a small set of essential	kernel processes run.
	    This mode is for administrative tasks such as installing optional
	    utilities packages.	 All files are accessible and no users are
	    logged in on the system.

     2	    Put	the system into	multi-user state.  All multi-user environment
	    terminal processes and daemons are spawned.

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

     4	    Define a configuration for an alternative multi-user environment.
	    This state is not necessary	for normal system operations; it is
	    usually not	used.

     5	    Stop the IRIX system and enter firmware mode.

									Page 1

init(1M)							      init(1M)

     6	    Stop the IRIX system and reboot to the state defined by the
	    initdefault	entry in inittab.

     a,b,c  Process only those inittab entries for which the run level is set
	    to a, b, or	c.  These are pseudo-states that can be	defined	to run
	    certain commands but do not	cause the current run level to change.

     Q,q    Re-examine inittab.

     S,s    Enter single-user mode.  When the system changes to	this state as
	    the	result of a command, the terminal from which the command was
	    executed becomes the system	console.

	    This is the	only run level that doesn't require the	existence of a
	    properly formatted 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.

	    The	set of filesystems mounted and the list	of processes killed
	    when a system enters system	state s	are not	always the same; which
	    filesystems	are mounted and	which processes	are killed depends on
	    the	method used for	putting	the system into	state s	and the	rules
	    in force at	your computer site.  The following paragraphs describe
	    state s in three circumstances: when the system is brought up to s
	    with init; when the	system is brought down (from another state) to
	    s with init; and when the system is	brought	down to	s with

	    When the system is brought up to s with init, the only filesystem
	    mounted is / (root).  Filesystems for users' files are not
	    mounted.  With the commands	available on the mounted filesystems,
	    you	can manipulate the filesystems or transition to	other system
	    states.  Only essential kernel processes are kept running.

	    When the system is brought down to s with init, all	mounted
	    filesystems	remain mounted and all processes started by init that
	    should be running only in multi-user mode are killed.  Because all
	    login related processes are	killed,	users cannot access the	system
	    while it's in this state.  In addition, any	process	for which the
	    utmp file has an entry is killed.  Other processes not started
	    directly by	init (such as cron) remain running.

	    When you change to s with shutdown,	the system is restored to the
	    state in which it was running when you first booted	the machine
	    and	came up	in single-user state, as described above.  (The
	    powerdown(1M) command takes	the system through state s on the way
	    to turning off the machine;	thus you can't use this	command	to put
	    the	system in system state s.)

     When an IRIX system is booted, init is invoked and	the following occurs.
     First, init looks in inittab for the initdefault entry (see inittab(4)).
     If	there is one, init usually uses	the run	level specified	in that	entry

									Page 2

init(1M)							      init(1M)

     as	the initial run	level for the system.  If there	is no initdefault
     entry in inittab, init requests that the user enter a run level from the
     virtual system console.  If an S or s is entered, init takes the system
     to	single-user state.  In the single-user state the virtual console
     terminal is assigned to the user's	terminal and is	opened for reading and
     writing.  The command /sbin/sulogin is invoked, which prompts the user
     for a root	password (see sulogin(1M)), and	a message is generated on the
     physical console saying where the virtual console has been	relocated.  If
     /bin/sulogin cannot be found, then	init attempts to launch	a shell:
     looking first for /bin/csh, then for /sbin/sh, then finally for /bin/ksh.
     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
     only re-initializes to the	single-user state if the inittab file does not

     If	a 0 through 6 is entered, init enters the corresponding	run level.
     Run levels	0, 5, and 6 are	reserved states	for shutting the system	down.
     Run levels	2, 3, and 4 are	available as multi-user	operating 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 inittab for boot and
     bootwait entries (see inittab(4)).	 These entries are performed before
     any other processing of inittab takes place, providing that the run level
     entered matches that of the entry.	 In this way any special
     initialization of the operating system, such as mounting filesystems, can
     take place	before users are allowed onto the system.  init	then scans
     inittab and executes all other entries that are to	be processed for that
     run level.

     To	spawn each process in inittab, 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 inittab,	init 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 inittab.	New entries
     can be added to inittab at	any time; however, init	still waits for	one of
     the above three conditions	to occur before	re-examining inittab.  To get
     around this, the init Q (or init q) command wakes init to re-examine
     inittab immediately.  Note, however, that if the inittab has been edited
     to	change baud-rates, those changes only take effect when new getty
     processes are spawned to oversee those ports.  Use	killall	getty to
     terminate all current getty processes, then init Q	to re-examine the
     inittab and respawn them all again	with the new baud-rates.

     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(2) 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	five seconds before forcibly terminating these processes via

									Page 3

init(1M)							      init(1M)

     the kill signal (SIGKILL).

     When init receives	a signal telling it that a process it spawned has
     died, it records the fact and the reason it died in /var/adm/utmp and
     /var/adm/wtmp if it exists	(see who(1)).  A history of the	processes
     spawned is	kept in	/var/adm/wtmp.

     If	init receives a	powerfail signal (SIGPWR) it scans inittab for special
     entries of	the type powerfail and powerwait.  These entries are invoked
     (if the run levels	permit)	before any further processing takes place.  In
     this way init can perform various cleanup and recording functions during
     the powerdown of the operating system.

     telinit, which is linked to /sbin/init, is	used to	direct the actions of
     init.  It takes a one-character argument and signals init to take the
     appropriate action.

FILES    [Toc]    [Back]

     /etc/inittab   default inittab file

SEE ALSO    [Toc]    [Back]

     getty(1M),	killall(1M), login(1), powerdown(1M), sh(1), shutdown(1M),
     stty(1), sulogin(1M), uadmin(1M), who(1), kill(2),	boot_cpuset(4),
     inittab(4), system(4), timezone(4), utmp(4), termio(7).

DIAGNOSTICS    [Toc]    [Back]

     If	init finds that	it is respawning an entry from the inittab file	more
     than ten times in two minutes, it assumes that there is an	error in the
     command string in the entry, and generates	an error message on the	system
     console.  It then refuses to respawn this entry until either five minutes
     has elapsed or it receives	a signal from a	user-spawned init or telinit.
     This prevents init	from consuming system resources	when someone makes a
     typographical error in the	inittab	file or	a program is removed that is
     referenced	in 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    [Toc]    [Back]

     init and telinit can be run only by a privileged user.

     The S or s	state must not be used indiscriminately	in the inittab file.
     A good rule to follow when	modifying this file is to avoid	adding this
     state to any line other than the initdefault.

									Page 4

init(1M)							      init(1M)

     If	a default state	is not specified in the	initdefault entry in inittab,
     state 6 is	entered.  Consequently,	the system loops; that is, it goes to
     firmware and reboots continuously.

     If	the utmp file cannot be	created	when booting the system, the system
     boots to state s regardless of the	state specified	in the initdefault
     entry in the inittab file.

     In	the event of a file table overflow condition, init uses	a file
     descriptor	associated with	the inittab file that it retained from the
     last time it accessed that	file.  This prevents init from going into
     single user mode when it cannot obtain a file descriptor to open the
     inittab file.

     The environment for init and all processes	directly started by is set
     initially from a table that is builtin, and then by parsing the file
     /etc/TIMEZONE.  Lines in that file	that are too long are ignored.

									PPPPaaaaggggeeee 5555
[ Back ]
 Similar pages
Name OS Title
inittab Tru64 Controls the initialization process
setpgrp2 HP-UX set process group ID for job control
profil FreeBSD control process profiling
profil OpenBSD control process profiling
setpgid HP-UX set process group ID for job control
profil NetBSD control process profiling
killpg HP-UX 4.2 BSD-compatible process control facilities
mpsched HP-UX control the processor or locality domain on which a specific process executes
vxiod HP-UX VERITAS Volume Manager I/O daemon process control device
getpid Tru64 Get the process ID, process group ID, or parent process ID
Copyright © 2004-2005 DeniX Solutions SRL
newsletter delivery service