init man page on IRIX

Man page or keyword search:  
man Server   31559 pages
apropos Keyword Search (all sections)
Output format
IRIX logo
[printable version]



init(1M)							      init(1M)

NAME
     init, telinit - process control initialization

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

DESCRIPTION
   init
     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
	    shutdown.

	    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
     exist.

     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
     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
     /etc/inittab   default inittab file
     /var/adm/utmp
     /var/adm/wtmp
     /etc/TIMEZONE
     /etc/ioctl.syscon
     /dev/console

SEE ALSO
     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
     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
     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.

									Page 5

[top]

List of man pages available for IRIX

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]
Tweet
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