Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

init(1m) [hpux man page]

init(1M)																  init(1M)

init - process control initialization SYNOPSIS
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 partic- ular 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 through 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 console 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 ini- tialization, 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 selected: 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 con- tents 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 sys- tem console. A message is generated on the physical system console, identifying 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 special initialization of the operating system, such as mounting file systems, 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 system 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 pro- cesses started from entries of type in the shell on the system console, and any processes started by the system adminis- trator. Administration 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 termi- nate 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 often 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 state NFS filesystems are often exported, as may be required for an NFS server. Activate graphical presentation managers and start other system processes. These states are available for user-defined operations. The default run level is usually run level or depending on the system configuration. 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 transi- tioning 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 hanging 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 processes 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 instanta- neous 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 levels permit) before any other processing takes place by boot In this way, boot can perform various cleanup and recording functions when- ever 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 priority 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 processes 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 terminated separately. A user can be invoked only by users with appropriate privileges. SECURITY FEATURES
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 behavior of this command. The currently supported parameters for boot authentication are: and On systems that have been converted to trusted mode, use the System Administration Manager (SAM) program (see sam(1M)). DIAGNOSTICS
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 system resources if there is a typographical error in the file or a program is removed that is referenced in WARNINGS
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) com- peting 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 functionality. FILES
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). STANDARDS CONFORMANCE
Man Page