This chapter describes the procedures for starting and stopping your system, bringing your system to the various default levels of operation, and creating your own custom levels of operation. The main sections are:
To start up an IRIX system, follow the steps in Procedure 3-1:
Procedure 3-1. Starting Up a System
Make sure all cables (such as power, display monitor, and keyboard) are properly connected. See your owner's guide and hardware guide for complete information about cabling your particular workstation or server.
Turn on the power switches on the display monitor (or console terminal) and the computer.
When you boot a system for the first time, you receive a Would you like to secure this machine now? message if an account (that is, root, guest, or other) has a NULL password. An answer of no changes nothing; a yes answer leads you through a short dialogue of prompts.
When you turn on the system, it runs power-on diagnostics and displays some copyright messages and some system startup information. These messages appear on the console screen or on the screen of a diagnostics terminal (an ASCII terminal connected to the first serial port) of a server. A copy of these messages is also written to the /var/adm/SYSLOG file in case you miss them.
If you are restarting the system after a power loss or other unexpected shutdown, you may see an error message regarding your SCSI bus or other hardware problem. This may be a temporary condition based on the disks' need to spin up to speed, or the SCSI bus may need to reset itself. Wait 30 seconds and attempt to boot the operating system again.
If the operating system determines that the filesystems need checking, it checks them with the fsck program (EFS only). fsck fixes any problems it finds before the operating system mounts the filesystems. fsck will run if the system is not shut down properly, such as in the event of a power failure. For information about using fsck, see the IRIX Admin: Disks and Filesystems guide and the fsck(1M) man page. Note that it is not necessarily a problem if fsck runs, it is merely a precaution.
The system now comes up in multiuser mode and you can log in. You should leave your system running at all times. The IRIX operating system works best when it is allowed to run continuously, so that scheduled operations and housekeeping processes can be performed on schedule.
To shut down the system from multiuser mode, perform the steps in Procedure 3-2:
Procedure 3-2. Shutting Down a System from Multiuser Mode
Use the who(1) command to determine which users are logged in to the operating system, if any:
who |
Notify users that the system is shutting down. Issue the wall(1M) command:
wall |
Enter your message. For example, you might enter:
There is a problem with the building's power system. I will be shutting down the system in 10 minutes. Please clean up and log off. Sorry for the inconvenience, norton |
When you finish entering your message, type Ctrl+D. The message is sent to all users on the system. They see something like this:
Broadcast Message from root Tue Oct 17 17:02:27... There is a problem with the building's power system. I will be shutting down the system in 10 minutes. Please clean up and log off. Sorry for the inconvenience, norton |
Enter the /etc/shutdown command:
/etc/shutdown -y -i0 -g600 |
The above command specifies a 10 minute (600 second) grace period to allow users to clean up and log off. The other flags indicate that the system will be completely shut down (-i0) and that the system can assume that all answers to any prompts regarding the shutdown are “yes” (-y). You see the following message:
Shutdown started. Fri Aug 28 17:10:57... Broadcast Message from root (console) Fri Aug 28 17:10:59 The system will be shut down in 600 seconds. Please log off now. |
After ten minutes, you see this message:
INIT: New run level: 0 The system is coming down. Please wait. |
The command monitor prompt or System Maintenance Menu appears. Wait for a command monitor prompt or System Maintenance Menu to appear before turning off power to the workstation or you may damage your hard disk.
Turn off the power.
For more information on shutting down the system, see the halt(1M) and shutdown(1M) man pages. Remember: Shut down the system only when something is wrong or if modifications to the software or hardware are necessary. The IRIX system is designed to run continuously, even when no users are logged in and the system is not in use.
If the system is in single-user mode, follow the steps in Procedure 3-3:
Procedure 3-3. Shutting Down a System from Single-User Mode
Use the shutdown command to turn off the system and guarantee filesystem integrity. As root, enter the command:
shutdown -y -i0 -g0
-y assumes yes answers to all questions, -i0 goes to state 0 (System Maintenance Menu), and -g0 allows a grace period of 0 seconds.
You see a display similar to this one:
Shutdown started. Fri Aug 28 17:11:50 EDT 1987 INIT: New run level: 0 The system is coming down. Please wait. |
The system stops all services and the command monitor prompt or System Maintenance Menu appears.
Wait for the command monitor prompt or System Maintenance Menu to appear or for a message that the system can be powered off before turning off power to the computer. Doing so prematurely may damage your hard disk.
Turn off power to the computer.
The IRIX system can run in either single-user or multiuser mode. In single-user mode, only a few processes are active on the system, no graphics are available, and only a single login is allowed. In multiuser mode, there can be multiple login sessions, many files open at once, and many active processes, including numerous background daemons.
The init program controls whether the system is in the multiuser or single-user state. Each possible state that the system can be in is assigned a label, either a number or a letter. The shutdown state is state 0. Single-user mode is state s.
Multiuser state labeling is more complex, because there can be great variations in multiuser states. For example, in one multiuser state, there can be unlimited logins, but in another state there can be a restricted number of logins. Each state can be assigned a different number.
The state of the system is controlled by the /etc/inittab file. This file lists the possible states, and the label associated with each.
When you bring the system to standard multiuser mode, init state 2, the following happens:
The filesystems are mounted.
Network services are started, if they are turned on.
The serial-line networking functions of uucp are available for use.
The spooling and scheduling functions of the lp package (if it is added to the system) are available for use.
Users can log in.
Not all activities can or should be performed in the multiuser state. Some tasks, such as installing software that requires the miniroot and checking filesystems must be done with the system in single-user mode.
There are many synonyms for the system state. These include:
init state
Run state
Run level
Run mode
System state
Likewise, each system state may be referred to in a number of ways; for example, single-user mode may be called:
Single user
Single-user mode
Run level 1
Table 3-1 shows the various possible states of the operating system as it is shipped. You can, of course, create your own custom states.
Run Level | Description |
|---|---|
0 | Power-off state. |
1, s, or S | Single-user mode is used to install/remove software utilities, run filesystem backups/restores, and check filesystems. This state unmounts everything except root, and kills all user processes except those that relate to the console. |
2 | Multiuser mode is the normal operating mode for the system. The default is that the root (/) and user (/usr) filesystems are mounted in this mode. When the system is powered on, it is put in multiuser mode. |
6 | Reboot mode is used to bring down the system and then bring it back up again. This mode is useful when you are changing certain system configuration parameters. |
The init process is the first general process created by the system at startup. It reads the /etc/inittab file, which defines exactly which processes exist for each run level.
In the multiuser state (run level 2), init scans the file for entries that have a tag (also 2) for the run level and executes everything after the third colon on the line containing the tag. For complete information, see the inittab(4) man page.
The system /etc/inittab looks something like the file in Example 3-1:
Example 3-1. /etc/inittab File
is:2:initdefault: fs::sysinit:/etc/bcheckrc </dev/console >/dev/console 2>&1 mt::sysinit:/etc/brc </dev/console >/dev/console 2>&1 s0:06s:wait:/etc/rc0 >/dev/console 2>&1 </dev/console s1:1:wait:/etc/shutdown -y -iS -g0 >/dev/console 2>&1 </dev/console s2:23:wait:/etc/rc2 >/dev/console 2>&1 </dev/console s3:3:wait:/etc/rc3 >/dev/console 2>&1 </dev/console or:06:wait:/etc/umount -ak -b /proc,/debug > /dev/console 2>&1 of:0:wait:/etc/uadmin 2 0 >/dev/console 2>&1 </dev/console RB:6:wait:echo "The system is being restarted." >/dev/console rb:6:wait:/etc/uadmin 2 1 >/dev/console 2>&1 </dev/console # |
This display has been edited for brevity; the actual /etc/inittab file is lengthy. If /etc/inittab is removed by mistake and is missing during shutdown, init enters the single-user state (init s). While entering single-user state, /usr remains mounted, and processes not spawned by init continue to run. Immediately replace /etc/inittab before changing states again. The format of each line in inittab is:
id:level:action:process |
id is one or two characters that uniquely identify an entry.
level is zero or more numbers and letters (0 through 6, s, a, b, and c) that determine in what level(s) action is to take place. If level is null, the action is valid in all levels.
action can be one of the following:
sysinit
Runs process before init sends anything to the system console (Console Login).
bootwait
Starts process the first time init goes from single-user to multiuser state after the system is started. (If initdefault is set to 2, the process runs right after the startup.) init starts the process, waits for its termination and, when it dies, does not restart the process.
wait
When going to level, starts process and waits until it has finished.
initdefault
When init starts, it enters level; the process field for this action has no meaning.
once
Runs process once. If it finishes, does not start it again.
powerfail
Runs process whenever a direct power-off of the computer is requested.
respawn
If process does not exist, starts it, waits for it to finish, and then starts another.
ondemand
Synonymous with respawn, but used only with level a, b, or c.
off
When in level, kills process or ignores it.
process is any executable program, including shell procedures.
# can be used to add a comment to the end of a line. init ignores all lines beginning with the # character.
When changing levels, init kills all processes not specified for that level.
When your system is up and running, it is usually in multiuser mode. It is only in this mode that the full power of the IRIX system is available to your users.
When you power on your system, it enters multiuser mode by default. (You can change the default by modifying the initdefault line in your inittab file.) In effect, going to the multiuser state follows these stages (see Table 3-1):
The operating system loads and the early system initializations are started by init.
The run-level change is prepared by the /etc/rc2 procedure.
The system is made public through the spawning of getty processes along the enabled terminal lines and, for networked systems, network access is enabled.
Just after the operating system is first loaded into physical memory through the specialized boot programs that are resident in the PROM hardware, the init process is created. It immediately scans /etc/inittab for entries of the type sysinit:
fs::sysinit:/etc/bcheckrc </dev/console >/dev/console 2>&1 mt::sysinit:/etc/brc </dev/console >/dev/console 2>&1 |
These entries are executed in sequence and perform the necessary early initializations of the system. Note that each entry indicates a standard input/output relationship with /dev/console. This establishes communication with the system console before the system is brought to the multiuser state.
Now the system is placed in a particular run level. First, init scans the table to find an entry that specifies an action of the type initdefault. If it finds one, it uses the run level of that entry as the tag to select the next entries to be executed. In the example /etc/inittab, the initdefault entry is run level 2 (the multiuser state):
is:2:initdefault: s2:23:wait:/etc/rc2 >/dev/console 2>&1 </dev/console co:23:respawn:/etc/gl/conslog t1:23:respawn:/etc/getty -s console ttyd1 co_9600 #altconsole t2:23:off:/etc/getty ttyd2 co_9600 # port 2 t3:23:off:/etc/getty ttyd3 co_9600 # port 3 t4:23:off:/etc/getty ttyd4 co_9600 # port 4 |
The other entries shown above specify the actions necessary to prepare the system to change to the multiuser run level. First, /etc/rc2 is executed which executes all files in /etc/rc2.d that begin with the letter S (see “Run-level Directories” for more information). When /etc/rc2 is executed, it accomplishes (among other things) the following:
Sets up and mounts the filesystems.
Starts the cron daemon.
Makes uucp available for use.
Makes the line printer (lp) system available for use, if installed.
Starts accounting, if installed and configured to be on.
Starts networking, if installed and configured to be on.
Starts the mail daemon.
Starts the system monitor.
To change run levels, the system administrator can use the telinit(1M) command that directs init to execute entries in /etc/inittab for a new run level. Then key procedures such as shutdown, /etc/rc0, and /etc/rc2 are run to initialize the new state. The telinit command is executed in the scripts single, multi, and reboot.
For example, to go from single-user mode to multiuser mode, enter:
multi |
Refer to the multi(1M), single(1M), and reboot(1M) man pages for more information.
Note that the preferred method of changing to a lower run state, such as single-user mode, is described in “Changing Multiuser Mode to Single-User Mode with the shutdown Command”. The new state is reached. If it is state 1 (single-user mode), the system administrator can continue.
Run levels 0, 2, and 3 each have a directory of files that are executed in transitions to and from that level. The directories are rc0.d, rc2.d, and rc3.d, respectively. All files in the directories are linked to files in /etc/init.d. The run-level filenames look like one of these forms:
SNNname
KNNname
The filenames can be split into three parts:
| S or K | The first letter defines whether the process should be started (S) or killed (K) upon entering the new run level. | |
| NN | The next two characters are a number from 00 to 99. They indicate the order in which the files will be started (S00, S01, S02, and so on) or stopped (K00, K01, K02, and so on). | |
| name | The rest of the filename is the /etc/init.d filename to which this file is linked. |
For example, the init.d file cron is linked to the rc2.d file S75cron and the rc0.d file K15cron. When you enter init 2, S75cron is executed with the start option: sh S75cron start. When you enter init 0, K75cron is executed with the stop option: sh K70cron stop. This particular shell script executes /sbin/cron when run with the start option and kills the cron process when run with the stop option.
Because run-level files are shell scripts, you can read them to see what they do. You can modify these files, though it is preferable to add your own since the delivered scripts may change in future releases. To create your own scripts, follow these rules:
Place the script in /etc/init.d.
Symbolically link the script to files in appropriate run-state directories, using the naming convention described above (that is, symbolically link the script file in /etc/init.d with SNNfile and KNNfile in the directories corresponding to the run levels at which you want to start and stop the script—usually /etc/rc2.d and /etc/rc0.d, respectively).
Be sure the script accepts the start and/or stop options to perform the start and stop.
Note that it may prove easier to simply copy an existing script from the directory and make appropriate changes. Look at the scripts and links in /etc/init.d, /etc/rc0.d, and /etc/rc2.d for examples of how to write the scripts.
Sometimes you must perform administrative functions, such as backing up the root filesystem, in single-user mode. To do so, use the shutdown command as shown in Procedure 3-4:
There are three recommended ways to start the shutdown to single-user mode:
You can enter the shutdown -i1 command (recommended). The option -g specifies a grace period between the first warning message and the final message.
You can enter the single command, which runs a shell script that switches to single-user mode and turns the getty processes off.
You can enter the init 1 command, which forces the init process to scan the table. The first entry it finds is the s1 entry, and init starts the shutdown process according to that entry.
This procedure executes all the files in /etc/rc0.d by calling the /etc/rc0 procedure. The shutdown command performs the following functions, among others:
Closes all open files and stops all user processes.
Stops all daemons and services.
Writes all system buffers to the disk.
Unmounts all filesystems except root.
The entries for single-user processing in the sample /etc/inittab are:
s1:1:wait:/etc/shutdown -y -iS -g0 >/dev/console 2>&1 </dev/console |
When the system is in the single-user environment, you can perform the appropriate administrative tasks.
The following entries in /etc/inittab power off the system:
s0:06s:wait:/etc/rc0 >/dev/console 2>&1 </dev/console of:0:wait:/etc/uadmin 2 0 >/dev/console 2>&1 </dev/console |
Always attempt to shut the system down gracefully. You can either enter the powerdown command, the init 0 command, or directly invoke the /etc/shutdown -i0 command.
In any case, the /etc/shutdown and /etc/rc0 procedures are called to clean up and stop all user processes, daemons, and other services and to unmount the filesystems. Finally, the /sbin/uadmin command is called, which indicates that the last step (physically removing power from the system) is under firmware control.