Text preview for : newadmin_1[1].pdf part of muk muki unix/linux
Back to : newadmin_1[1].pdf | Home
Performing the Full Installation
Most systems automatically reboot off the newly installed disks after the software subsets are loaded. If your system does not have this capability, the screen displays the boot commands required to boot from the newly created system disk. At the console prompt (>>>), enter the boot command sequence shown on your screen. Software configuration begins after the system boots. If you did not provide certain essential site-specific information (such as a root password, your system's host name, the date and time, and location and time zone) earlier in the installation procedure, you will be prompted to enter that information now. The kernel build procedure begins after software configuration. If you chose the option to customize kernel component selection during the full installation setup, a Kernel Option Selection menu is displayed after the system reboots. After you select and confirm your kernel options, you have the option to edit the configuration file. When the subsets are configured and the configuration file is completed, the installation procedure builds the kernel for your system.
Post Installation Login and Setup
When you log in to the system (with graphics capability) for the first time, the CDE login window is displayed. Enter root as the username and then enter the root password specified at the beginning of the installation. When you correctly enter this information, the following CDE components are displayed: The System Setup application appears, offering three setup options: Quick Setup invokes a wizard-like application that steps you through a basic set of system configuration tasks to let you quickly set up your system for general use. Custom Setup contains a complete list of configuration applications. Cloning provides information about the configuration cloning capability. Configuration cloning lets you replicate the configuration from a system that is already configured. Configuration cloning is documented in the Installation Guide -- Advanced Topics. The CDE Front Panel appears at the bottom of your screen.
Installation Log Files
The installation process creates a set of log files in the /var/adm/smlogs directory: The configuration description file used in cloning (for more information, see the Installation Guide - Advanced Topics):
/var/adm/smlogs/install.cdf
The general log file:
/var/adm/smlogs/install.log
3 24
Installing the System
The file system creation logs:
/var/adm/smlogs/install.FS.log
The log for the setld(8) utility:
/var/adm/smlogs/setld.log
The verification log file:
/var/adm/smlogs/fverify.log
Configuration Cloning
Configuration cloning lets you duplicate the configuration from an already-configured system onto one or more target systems, eliminating the need to perform the configuration tasks as a separate operation. It is recommended that you use Configuration cloning to clone systems with similar hardware and functions. Configuration cloning is ideal for cloning the same class or type of machine (for instance, all workstations or all servers). The criteria for determining whether cloning is suitable for your situation is if the systems are of the same type and have the same number and type of network adapters. Instead of configuring each system individually, you configure a single system, then replicate that model configuration among other systems of the same class or type. You can also use the configuration cloning process to restore the configuration of a system if the current configuration becomes corrupted or if you want to go back to a previous configuration. When a system you designate to be a model system has been fully configured the way you want it, you use the sysman -clone -save command to save a snapshot of the system configuration data into a configuration description file (CDF). This file is named config.cdf, and it is saved in the /var/adm/smlogs directory by default. The information saved in the config.cdf file is used to duplicate the same configuration on similar systems. You may edit the config.cdf file and change any value (except the checksum), but there are certain host-specific attributes (such as host name and IP address) that must be edited to retain a unique network identity for the cloned systems. The config.cdf file can be applied automatically to another system during a Full Installation process or can be applied manually after the system to be cloned is installed but is not yet configured. The following list summarizes your options: To manually clone one system at a time, edit the config.cdf file to set host- and site-specific attributes, copy the CDF to the target system, and manually apply the CDF to an installed target system using the sysman -clone -apply command. To clone one system during a Full Installation, edit the config.cdf file to set hostand site-specific attributes.
3 25
Configuring the System with Quick Setup
Configuring the System with Quick Setup
This section describes how to perform basic system configuration tasks using the Quick Setup utility. You run the Quick Setup utility immediately after completing an installation.
Note Quick Setup is only available on systems with graphics capabilities. On systems that do not have graphics capabilities, use the /usr/sbin/setup utility to perform initial configuration tasks.
Tru64 UNIX System Setup Window
When you first boot your system after performing an installation, the Tru64 UNIX System Setup window appears. This window provides three options: Quick Setup Custom Setup Cloning Information Choose the Quick Setup option. This allows you to quickly set up your system for general use. Quick Setup is a task-oriented application that leads you step-by-step through basic configuration tasks. It also has online help if you need assistance. If you need to configure additional items, you have the option to use the Custom Setup application at a later time.
3 26
Installing the System
Figure 3-12 Tru64 UNIX System Setup Window
Note
Although Quick Setup is normally run from the System Setup window immediately after installation of the Tru64 UNIX operating system, you can also access the utility by clicking on the General Tasks item in the SysMan Menu.
Quick Setup Menu Window
After you select Quick Setup in the Tru64 UNIX System Setup window, the Quick Setup Menu window appears. This window displays the following sequential steps that comprise the Quick Setup application: Step 1: Enter basic license information Step 2: Set up the system's Network Interface Card (NIC) Step 3: Set up network routing services Step 4: Specify a Domain Name Service (DNS/BIND) server
3 27
Configuring the System with Quick Setup
Step 5: Specify a Network Time Protocol (NTP) server Step 6: Specify a Network Information Service (NIS) server Step 7: Set up Network File System (NFS) services Step 8: Set up an E-Mail server Step 9: Set up a default printer and its server
Figure 3-13 Quick Setup Menu Window
Note that, when performing the steps in the Quick Setup menu, you can skip any step. No action is performed until you review and approve a summary of the setup at the end of Quick Setup. Click on Next> in the Quick Setup Menu window to move to Step 1.
3 28
Installing the System
Entering Basic License Information
After you click on Next> in the Quick Setup Menu window, the Enter Basic License Information window appears. The Enter Basic License Information window prompts you to enter the basic license information contained on the OSF_BASE license sheet that was distributed with the system. Specify the following information in the Enter Basic License Information window: Authorization Number Number of Units Key Termination Date Checksum
Figure 3-14 Enter Basic License Information Window
When you have entered the information, click on Next> to move to the Set Up the Network Interface Card (NIC) window.
3 29
Configuring the System with Quick Setup
Setting Up the Network Interface Card (NIC)
The Set Up the Network Interface Card (NIC) window prompts you to enter the information that identifies your system to the network. This information includes: Host Name - a unique name you give to your system System IP Address - a unique, 32-bit number assigned to your system, written as four numbers separated by periods Network Mask - a 32-bit number that informs the system which bits of the Internet address to interpret as the network and subnetwork addresses and which bits to interpret as the host address
Figure 3-15 Set Up the Network Interface Card Window
You can choose any host name you want, but remember that you must obtain an IP address for a unique host name by registering the system for internet use. You can obtain the network mask for the system from the network administrator at your site. After you have entered the relevant information in the Set Up the Network Interface Card (NIC) window, click on Next> to move to the Set Up Network Routing window.
3 30
Installing the System
Setting Up Network Routing
The Set Up Network Routing window lets you choose a routing service daemon (routed or gated), or enter the IP address of the default static route gateway. This choice determines how your system communicates with the network. The routed and gated daemons are system routing table management facilities that are configured to update routing tables dynamically. Static routing involves designating a routing system and placing entries in the routing tables manually. You can determine the routing choices to make for your system from your local network administrator.
Figure 3-16 Setup Network Routing Window
After you have selected a network routing method, enter Next> to move to the Specify the Domain Name Service window.
3 31
Configuring the System with Quick Setup
Specifying the Domain Name Service (DNS/BIND)
Domain Name Service (DNS) servers, also known as Berkeley Internet Name Domain (BIND) servers, translate host names into IP addresses. The Specify the Domain Name Service window allows you to configure your system as a DNS client, allowing your system to obtain host names and addresses from DNS servers you designate. The Specify the Domain Name Service window prompts you to enter the following information: DNS Network Domain Primary DNS Server Name Primary DNS Server IP Address Secondary DNS Server Name (optional) Secondary DNS Server IP Address (optional) You can obtain this information from your local network administrator.
Figure 3-17 Specify the Domain Name Service Window
After you have chosen a network routing method, enter Next> to move to the Specify the Network Time Protocol window.
3 32
Installing the System
Specifying the Network Time Protocol (NTP)
The Specify the Network Time Protocol window lets you enter the host name of an NTP server that will keep your system's time synchronized with an accurate time service. You can specify one, two, or three NTP servers, but only one is required. You can obtain this information from your local network administrator.
Figure 3-18 Specify the Network Time Protocol Window
After you have specified the NTP server information, enter Next> to move to the Specify the Network Information Service window.
3 33
Configuring the System with Quick Setup
Specifying the Network Information Service
The Specify Network Information Service window lets you enter the host name of an NIS server that serves information about user accounts and groups. The Specify Network Information Service window prompts you for the following information: NIS Domain Primary NIS server name Secondary NIS server name (optional) You can obtain this information from your local network administrator.
Figure 3-19 Specify the Network Information Service Window
After you have entered an NIS domain and server name, enter Next> to move to the Specify NFS Services window.
3 34
Installing the System
Specifying NFS Services
The Specify NFS Services window allows you to indicate whether or not you want to allow the system to mount directories remotely from other systems, or to export its directories to other systems. The window provides the following choices: Enable remote directory mounting Enable automounting Enable directory exporting You can obtain this information from your local network administrator.
Figure 3-20 Specify NFS Services Window
After you have chosen which NFS services you want to enable, enter Next> to move to the Specify an E-mail Server window.
3 35
Configuring the System with Quick Setup
Specifying an E-mail Server
The Specify an E-mail Server window allows you to specify the name of the server that will provide E-mail to your system. You can obtain this information from your local network administrator.
Figure 3-21 Specify an E-mail Server Window
After you have designated an E-mail server, enter Next> to move to the Specify a Default Printer and Print Server window.
3 36
Installing the System
Specifying a Default Printer and Print Server
The Specify a Default Printer and Print Server window lets you enter the name of a network printer that handles print jobs by default. You can also enter the host name of the server that serves that printer. You can obtain this information from your local network administrator.
Figure 3-22 Specify a Default Printer and Print Server Window
The Specify a Default Printer and Print Server window completes the series of Quick Setup information entry windows. After you have chosen a printer and print server, enter Next> to move to the Quick Setup Summary window.
3 37
Configuring the System with Quick Setup
Summarizing Quick Setup Choices
As you complete the data entry steps of the Quick Setup procedure, the information you enter is stored in a temporary buffer. No action that you specify is performed until you review and approve a summary of the setup at the end of Quick Setup. The summary is contained in two summary windows, the Quick Setup Summary (First Page), and the Quick Setup Summary (Last Page). The Quick Setup Summary (First Page) summarizes the basic license, Network Interface Card, network routing, and DNS/BIND information you entered.
Figure 3-23 Quick Setup Summary Window (First Page)
The Quick Setup Summary (Last Page) summarizes the NTP, NIS, NFS, E-mail, and printer information you enter.
3 38
Installing the System
Figure 3-24 Quick Setup Summary Window (Last Page)
After you have reviewed all the information in the Quick Setup Summary (First Page) and the Quick Setup Summary (Last Page), click on Finish in the Quick Setup Summary (Last Page) window to set up the system using this information.
3 39
Configuring the System with Quick Setup
Completing Quick Setup
Once the setup is complete, you receive a "You are Done" message. This indicates that the Quick Setup tasks have been performed and that you can move on to other system administration tasks.
Figure 3-25 Quick Setup You Are Done! Message
3 40
Installing the System
Performing an Update Installation
Overview
Use the update installation to update Alpha systems running V4.0G or V5.0A to V5.1. If your system has an earlier version installed, you must either perform successive updates to reach V5.1 or perform a full installation. This upgrade installation process will also be used in future releases of the operating system. You can initiate an update installation by running the installupdate command. Before you run this utility, ensure that: Your current system is running V4.0G or V5.0A You have upgraded your firmware appropriately You have enough disk space Also be aware of the following: There can be no changes of symbolic links to directories or, conversely, no location changes of directories that have symbolic links. Certain layered products cause the update installation to quit. You need to remove these layered products before doing an update installation: DECnet Internationalization Open 3D
Update Install Features
Update installation provides both a graphical and textual interface. If your system has graphics capability, it presents the graphical interface. If your system does not have graphics capabilities, the text interface is presented. If your system has graphics capability, but you want to use the text interface, you can force the text interface. Table 3-4 summarizes the features of an update installation.
Table 3-4 Update Installation Feature Summary
Feature
Removes conflicting software Updates Worldwide Language Support (WLS) software Executes instructions provided in user-supplied files File type checking
Description
Can remove layered products that would prevent update from successfully completing. Automatically detects and updates WLS software if it is loaded on your system. Lets you customize and extend updated installations through the use of user-supplied files. Checks for system file types that are changed. If a file type conflict is found, you will be notified, and the program will exit. Lets you select the kernel options you need to run your applications.
Kernel options selection
3 41
Performing an Update Installation
Table 3-4 Update Installation Feature Summary (Continued)
Feature
Disk space recovery
Description
Provides the option to remove unnecessary software subsets and .PreUPD, core and extra kernel files to recover disk space. Can run unattended if you do not need to select kernel options or archive obsolete files.
Unattended update installation
Preparing for the Update Installation
Perform the following tasks before you begin an update installation: 1. Read the Release Notes and the Installation Guide. 2. Back up the current operating system. 3. Update system firmware. 4. Make sure you have enough memory and disk space. 5. If you do not already know it, determine the CD-ROM device name. 6. If you have AdvFS file systems on your system, shut down to single-user mode and verify each file system to protect the data on AdvFS file domains.
Starting the Update Installation
Before beginning the update installation, be aware that the process takes from 45 to 120 minutes to complete. Actual time depends on your processor type, the speed of your CD-ROM drive, and the number of software subsets to be updated.
Note Once you start an update installation, you cannot stop it. If you do, you are likely to lose system files.
1. Determine the device name of the CD-ROM drive on your system. Issue the following command on the running system to determine the correct device.
# file /dev/disk/cdrom*c /dev/disk/cdrom0c: block special (19/85) # The CD-ROM device name in this example is cdrom0c.
2. Shut down the system and then boot to single-user mode. 3. Verify the AdvFS domains. 4. Mount the local file systems as follows:
# /sbin/bcheckrc
An update installation is performed from single-user mode.
The bcheckrc command also runs fsck on UFS file systems. 5. Ensure that the CD-ROM is loaded in the drive. 6. Do one of the following to start the installupdate from CD-ROM. If you are updating from a network server, go to step 7:
3 42
Installing the System
Enter the installupdate command with the following syntax:
/sbin/installupdate cdrom_device
The cdrom_device parameter is the device special file name of the CD-ROM drive. For example, to use CD-ROM device dsk4c, enter the following command:
# /sbin/installupdate /dev/disk/cdrom0c
Enter the following command if the CD-ROM device already is mounted:
/sbin/installupdate mount_point
The mount_point parameter specifies the mount point of the CD-ROM device. For example, if the CD-ROM is mounted on /cdrom:
# /sbin/installupdate /cdrom
Enter the following command if your system has graphical display capability, but you want to use the text interface:
/sbin/installupdate -nogui mount_point
7. Use the following commands only if Tru64 UNIX Version 5.1 is available on a RIS server, and your system is registered to receive Version 5.1 from the server. a. Enter the following command to ensure that routed and gated daemons do not start up during update installation (if you do not run routed or gated, you can skip this command):
# route flush
b. Start the update installation using the installupdate command syntax:
/sbin/installupdate RIS_server_name:
Be sure to follow the RIS server name with a colon as shown.
Choosing Update Installation Options
What you see after you enter the installupdate command depends upon whether your system has graphical display capability. If it does, the Update Installation window appears. If your system lacks graphical display capability or you used the installupdate nogui command option, an Update Installation menu with the text shown in the Update Installation window will appear. You can choose the following options: Select optional kernel components Choose this option if your current system is running a customized kernel that has been built with optional components, or if you want to customize your new kernel. Archive obsolete files
3 43
Performing an Update Installation
Choose this option to archive obsolete files before the update removes them. Obsolete files are those that were shipped in an earlier version, but are no longer required by the current version. If you choose to create a custom kernel, update installation lets you choose individual kernel options. If you choose to save obsolete files, update installation pauses upon the discovery of obsolete files and lets you save them to a default backup.tar file, or a file of your choice. The program then runs through a preload analysis. The following system analysis is performed automatically: Checking for conflicting software Determining installed base operating system software Determining kernel components Checking for file type conflicts Checking for obsolete system files Checking file system space When the preload analysis is complete, the update installation loads software subsets. Update installation automatically removes obsolete files and builds a kernel with all mandatory and optional components for the installed software subsets.
Postinstallation Tasks
After the update installation is complete, log in to the system as root. It is recommended that you examine the log files when the update is complete to ensure that there were no errors during the update and that all files merged successfully. The update installation log is located in:
/var/adm/smlogs/update.log
Information about the system configuration is located in:
/var/adm/smlogs/it.log
The list of customized files is located in:
/var/adm/smlogs/upd_custom_files
The list of failed merges is located in:
/var/adm/smlogs/upd_mergefail_files
Use the update installation cleanup utility to remove or archive the .PreMrg and .PreUpd backup files created by an update installation. This is available from the SysMan Menu by selecting the: 1. Software branch 2. Installation branch 3. Cleanup after an OS update (updadmin) task
3 44
Installing the System
Learning Check
1. An ______________ preserves disk partitions, file systems, file customizations, network and print environment, user accounts, user-created files, and any other setup you may have installed on the system. 2. List the preparatory steps you must take before beginning an installation. 3. Use the _____________ window to choose which options to build into the kernel later in the installation process. 4. The _________ utility allows you to set up your system for general use after a full installation. 5. __ The update installation log is located in: a. /var/adm/smlogs/upd_mergefail_files b. /var/adm/smlogs/it.log c. /var/adm/smlogs/update.log d. /var/adm/smlogs/upd_custom_files
3 45
Learning Check
3 46
Performing System Startup and Shutdown
Module 4 Introduction
As system manager, you must know how to boot your system to single-user and multiuser mode. You may also have to add or monitor system resources in single-user mode. In these cases, you must shut down and reboot your system or shut down to single-user mode. You may even have to modify the system startup procedures. This module discusses booting UNIX systems and gives background information on what happens on a UNIX system as it boots. It also discusses the shutdown, halt, reboot, and init commands you use to shut down, reboot and change run levels on a UNIX system. Finally, it provides information about, and examples of, the initialization files.
Objectives
To effectively control system startup and shutdown, you should be able to: Bootstrap a powered-down or halted system and describe how the init command changes system run levels Shut down to single-user mode or the halt state using the command line interface (CLI) Shut down to single-user mode or the halt state using the Common Desktop Environment (CDE) shutdown application Describe the system initialization files
Resources
For more information on the topics in this module, see the following: Tru64 UNIX System Administration, Chapters 2 and 3 UNIX System Administration Handbook, Nemeth, Snyder, & Seebass, Chapter 2 The Design and Implementation of the 4.3BSD UNIX Operating System, Leffler, McKusick, Karels, and Quarterman, Chapter 13
41
Booting a Tru64 UNIX System
Booting a Tru64 UNIX System
Overview
Bootstrapping, more commonly called booting, is the process of starting up a computer from a powered-down or halted condition. During the boot process, the operating system kernel is loaded into memory and started. Many tasks must be performed during this process to initialize the system before it can be used. You boot the local system manually from the console, or remotely via a connection. You can set the system to reboot immediately following an intentional shutdown that you initiated by including the reboot option as part of the shutdown procedure.
Determining the Boot Device
Before you can boot your system, you need to determine which device on your system contains the operating system. The system manager at your local site should be able to tell you which device is the boot device. Alternatively, you can identify the devices on your system when your system is halted at the console prompt with the show device command.
Setting Console Boot Variables
Booting the operating system is performed from the system's console firmware. Table 4-1 lists some of the console environment variables that affect booting.
Table 4-1 Console Variables for Booting
Variable
auto_action boot_osflags bootdef_dev boot_file cpu_enable
Action
Identifies the action to take on system power-up, reset, or when the system crashes; when set to halt, halts the system at the console prompt Identifies a combination of flags used to control the boot loader and kernel Identifies the default boot device Identifies the kernel to boot Selectively enables particular processors from the console
Options to the boot_osflags variable are listed in the following table.
Table 4-2 Options to the boot_osflags Variable
Option
a s k d c e i
Action
Boots to multiuser mode; by default, the kernel boots to single-user mode Boots to single-user mode Debugs the kernel using the kdebug debugger; by default, kernel debugging is off Uses full crash dumps; by default, partial dumps are used Boot without reading the sysconfigtab file Use the ikdebug debugger to debug the kernel Prompts for the kernel and special arguments; by default, no questions are asked
42
Performing System Startup and Shutdown
Display the current value of a variable with the show command. Change the value with the set command.
Overriding the Console Boot Variables
The following list describes how to override the console boot variables. Overriding bootdef_dev To override the bootdef_dev variable, supply the desired boot device as an argument to the boot command. For example, if your boot device is set to boot from disk dka0 and you want to boot from disk dkb0, enter:
>>> boot dkb0
Overriding boot_osflags To override the boot_osflags variables, pass the desired choices to the -fl option. For example, the following command boots to the interactive prompt so you can specify an alternate kernel, and then boots to multiuser mode:
>>> boot -fl ai
Overriding boot_file The UNIX operating system allows you to start an alternate kernel. For example, if you cannot start your system, you could start the generic kernel, /genvmunix, to troubleshoot the problem with your system. You could also boot an alternate kernel to test new drivers or to add options to the existing kernel. To start a kernel other than that specified by boot_file, enter the boot command with the following syntax:
boot -fi kernel
For example, to boot the genvmunix kernel, enter:
>>> boot -fi genvmunix
The consvar Command
Use the consvar command to manipulate console environment variables from the running operating system. The -l option lists the values of all variables supported by the platform that are not disabled. This is similar to the show SRM console command. The -v option displays system IDs used by firmware, the current firmware revision, and information about the process. The -g option gets the value of the specified console environment variable. The -s option sets the value of the specified console environment variable. The following example gets the value of the booted_dev variable:
# consvar -g booted_dev booted_dev = dsk0
43
Booting a Tru64 UNIX System
Booting the System
If you are preparing to reboot your system from a powered-down state, follow these steps: 1. Confirm that the hardware and all peripheral devices are connected. 2. Power up the hardware and peripheral devices. 3. Confirm that the hardware completed its restart and diagnostic operations. 4. At the console prompt (>>>), enter the boot command.
>>> boot
Stages in Booting
The boot process can be divided into seven stages: 1. Load the kernel of the operating system into memory. a. The console software reads and executes the contents of logical block number (LBN) 0 (the boot block). b. The code from block 0 reads the primary bootstrap code from LBN 1-15. c. This code loads the secondary bootstrap program /osf_boot. d. The secondary bootstrap program is a more intelligent loader program. It takes information about the boot mode, the boot device type, how and what to boot, and loads the specified kernel. The boot loader can communicate with the operator by issuing general and error messages and by accepting input. 2. Initialize the kernel and memory management. Once the kernel has been loaded, it starts executing and initializing itself. During kernel initialization, the kernel: a. Displays the total amount of memory and how much memory is left after loading the kernel b. Reads sysconfigtab and then calls alpha_init c. Reserves I/O memory for the buffer cache and for internal static tables d. Sets up page tables and enables memory management e. Creates the environment for process 0 and several system server threads 3. Check hardware configuration. The kernel identifies hardware devices on the system and loads appropriate device drivers. 4. Create two system processes: kernel idle (process 0) and init (process 1) Process 0, the kernel idle task, is multithreaded; it consists of many threads to perform such activities as paging and swapping memory, scheduling threads, servicing device interrupts, and handling idle time.
44
Performing System Startup and Shutdown
Process 1, init, is the first process to execute a program in user mode, and is the parent process to all subsequent processes. 5. Superuser intervention at single-user mode. Boot to single-user mode to perform administrative tasks that are best accomplished with no other users on the system. 6. Execute the initialization script files. 7. Begin multiuser operation.
Run Levels
A run level specifies the state of the system and defines which processes are allowed to run at that state. You can specify the initial run level (single-user or multiuser) by using an argument to the boot command. Once the system is up and running, the root user can use the init command to change run levels. For example, for a system at run level three, the command init 2 would cause a change to run level two. The command init s would cause a change to singleuser mode. The command init 0 would halt the system. During a change in run levels, init scans the /etc/inittab file to determine which commands and scripts to execute. Run levels include:
Level
0 1, S, or s 2 3
Description
Halt state Single-user mode with no paging, no swapping Multiuser mode with no network; security and paging/swapping enabled Multiuser mode with network services
You can use the who -r command to show the current run level.
Working in Single-User Mode
You can boot to single-user mode to perform administrative tasks that are best accomplished with no other users on the system. For instance, you might be checking out new hardware, mounting and monitoring file systems, or changing disk partitions. If the system is booted to single-user mode, only the root file system is mounted. If you need a program that is not in the root partition, you must mount the required file system. In addition, the root file system is mounted for read-only access. To write to the root file system, you must change the access using the mount -u command. Because the daemons are not running at this time, many commands that depend upon server processes will not function properly (such as mailx). When you exit single-user mode with or exit, the init process continues with the startup tasks to transition to multiuser mode.
45
Booting a Tru64 UNIX System
Executing Initialization Scripts
During a system boot, the init process scans each line in the /etc/inittab file and executes the command on each line containing the number of the run level that the system is changing to. The init process executes the rc (run command) script files. The names of these files vary among the various UNIX implementations. In Tru64 UNIX and System V systems, the init process determines which script files should be run based upon entries in the /etc/inittab file. The init process spawns a copy of the Bourne shell to run the script files. Some tasks performed by the rc* scripts are: Setting the name of the system Checking the file systems with fsck Mounting the file systems listed in the /etc/fstab file Removing files from the /tmp directory Notifying the kernel of additional swap partitions Starting up daemons and network services Turning on system accounting and disk quotas Configuring network interfaces Enabling logins
Multiuser Mode
Depending upon the system, a getty process may be started for the console, or for a workstation, a CDE process is started. If a getty process terminates, the init process restarts it. Remote logins are not accepted unless the network has been started.
Troubleshooting Boot Problems
Should your system not boot, the following list suggests some areas for further investigation: Hardware failure Check the hardware manual accompanying your system for hardware test procedures. If a hardware problem exists, follow the instructions in the guide for resolving the problem. An incorrect boot path was specified Check your system's hardware guide for instructions on determining and specifying the correct boot path. Changed parameter
46
Performing System Startup and Shutdown
You may have changed a parameter that makes it impossible for the system to boot. Try booting using -fl c to bypass the sysconfigtab file. The kernel is corrupt If you suspect that the kernel may be corrupt, try booting the generic kernel, genvmunix. A disk or file system is corrupt If a UFS file system is corrupt, run the fsck or verify command on the file system. Use extreme care under these circumstances so that you do not inadvertently overwrite or remove any files.
Creating a Bootable Tape
You can create a bootable standalone system (SAS) kernel on tape. The SAS kernel has a built-in memory file system (mfs), which contains the minimum commands, files, and directories needed to restore the system image. This is referred to as the miniroot file system. You can also add additional file systems to the tape for data or programs that you may need. To create the SAS kernel, you must use the bttape interface or the btcreate command line utility. Once you have created the kernel, you can restore the customized image using the btextract utility. To build a bootable SAS kernel on UFS or AdvFS file systems only, you must use the btcreate utility. The btcreate utility provides both a noninteractive and interactive user interface. Both require that you have superuser (root) privileges. To run the btcreate utility in interactive mode, invoke the utility without any options or a subset of the options; you are then prompted for all or any missing information. The btextract utility extracts the file systems from tape in single-user mode in memory. The btextract utility is a shell script that restores file systems from tapes that contain the bootable Standalone System (SAS) kernel. After the btextract utility completes its task, you must shut down the system, then reboot the system from the restored disk.
47
Shutting Down and Rebooting the System
Shutting Down and Rebooting the System
Overview
Shutting down and rebooting the system are routine tasks a system administrator performs periodically. Usually you can shut down the system with minimal disruption to the users. Occasionally, you might have to shut it down quickly, forcing users to log off immediately. Sometimes the system shuts itself down suddenly, without warning. This section describes various methods for shutting down and rebooting the system.
Reasons for System Shutdown and Reboot
Although many system management tasks can be performed while the system is up and running, there are several instances where you will need to reboot the operating system, or power down the computer. Adding new hardware Before you add new hardware, the system must be powered down. After the hardware is installed, you may need to modify the kernel configuration file and rebuild the kernel. Updating system software To install a new version of system software, shut down the system and boot from the distribution media. To upgrade system software, you may have to shut down as well. Installing layered products To install a layered product, you may need to shut down the system to single-user mode, install the software, make some changes to the configuration file, then build a new kernel and reboot the system. (Note: not all layered products require changes to the configuration file and building a new kernel.) System tuning If you modify the system by altering option values in the configuration file to enhance system performance, you may need to build a new kernel and reboot the system. File system corruption File systems can become corrupted by improper shutdown procedures, by hardware failures, or by power outages and surges. If you suspect file system corruption, shut down and reboot to check or restore the file system. Hardware errors If you notice several errors of the same type in the event log, you may suspect an impending hardware failure. You may want to shut down the system to more closely examine the suspect hardware.
48
Performing System Startup and Shutdown
Methods for System Shutdown
A system shutdown involves a change from multiuser mode to single-user mode or to a halted state. Shutting down a system requires root (superuser) privileges. There are a number of ways you can shut down your UNIX system. You can: Use the CDE Shutdown manager Use the shutdown command Use the halt or fasthalt command Use the init command Send a signal to the init process Figure 4-1 provides an overview of various commands used to shut down or reboot a UNIX system.
Figure 4-1 Overview of System Shutdown and Reboot
halt, fasthalt reboot, fastboot >>>
Halt Mode
>>>
boot
shutdown -h, init 0
Single User Mode
shutdown -r, reboot # shutdown, init s
Multiuser Mode
sm0301
Using the shutdown Command
Use the shutdown command to halt, reboot, or return to single-user mode. The command provides the most consideration for other users. You must be root to execute this command. The format for the shutdown command is:
shutdown [-bfhknrsc] shutdowntime [warning-message]
49
Shutting Down and Rebooting the System
The shutdown options are listed in Table 4-3.
Table 4-3 shutdown Command Options
Option
none -b -f -h -k -n -r -s -c
Description
Shuts down to single-user mode. Sends a shutdown message to the rwalld daemon on all remote client hosts that have NFS file systems mounted from this system. Shuts down fast, bypassing the messages to other users. Does not unmount disks. Shuts down and halts at console level (>>>). Sends a message to all users, warning them of an impending shutdown. The system does not actually shut down. Shuts down without synchronizing the disks or logging the shutdown. Shuts down and automatically reboots the system. Runs the stop scripts. This flag is optional, and can only be used with either the -r flag or the -h flag. Shuts down and halts all members of a cluster in an orderly fashion. The -h and -s options are invoked by default when the -c option is specified. That is, there is no difference between specifying the -c option alone and specifying -csh. If any options other than -h and -s are specified with the -c option, the shutdown command displays a usage message and exits.
The time argument specifies when shutdown will bring down the system. Use the following formats:
Format
now
Description
Shuts down the system immediately Shuts down the system in number minutes Shuts down the system at the absolute time specified; the hours and minutes may be separated by a colon (:)
+number yymmddhhmm
The final argument is the warning message you want sent to all users currently logged in to the system. This optional message is sent along with the shutdown notification message at increasingly shorter intervals as the time for shutdown approaches.
Shutting Down to Single-User Mode
When used without any options, the shutdown command brings the system to singleuser mode. The system notifies all users of the impending shutdown. An example shutdown command might look like the following:
# shutdown +10 System coming down for routine maintenance In a shutdown to single-user mode, the shutdown command does the following:
Runs the wall command (with your message) to notify all users of the impending shutdown Disables new logins Stops accounting and event logging Logs the shutdown in the event log file and /var/adm/wtmp
4 10
Performing System Startup and Shutdown
Stops all remaining processes Sends the terminate signal to the init process, which brings the system to singleuser mode Shutdown is complete when the system console displays single-user mode.
ral-zk41# shutdown now Shutdown at 17:10 (in 0 minutes) [pid 1186] ral-zk41# *** FINAL System shutdown message from [email protected] *** System going down IMMEDIATELY ... System shutdown time has arrived INIT: New run level: S The system is coming down. Please wait... Logins disabled LAT stopped. Unmounting NFS filesystems Halting processes ... INIT: SINGLE-USER MODE #
In single-user mode you have superuser access to the system through the console, using the Bourne shell to perform administrative tasks. You can use the process status (ps -aef) command to illustrate the effect of a shutdown to single-user mode. First, issue the command while the system is still in multiuser mode. The output might look like that shown in Example 4-1.
Example 4-1 Typical Multiuser Mode ps Output PID PPID C STIME TTY TIME CMD 0 0 5.4 Oct 24 ?? 08:05:54 [kernel idle] 1 0 0.0 Oct 24 ?? 0:03.35 /sbin/init -a 3 1 0.0 Oct 24 ?? 0:00.32 /sbin/kloadsrv 5 1 0.0 Oct 24 ?? 0:00.75 /sbin/hotswapd 16110 1 0.0 14:03:37 ?? 0:00.03 /sbin/update 16223 1 0.0 14:03:43 ?? 0:01.21 /usr/sbin/evmd 16260 16223 0.0 14:03:46 ?? 0:00.12 /usr/sbin/evmchmgr -l /var/evm/adm/logfiles/evmchmgr.log root 16263 16223 0.0 14:03:46 ?? 0:00.22 /usr/sbin/evmlogger -o /var/run/evmlogger.info -l /var/evm/adm/logfiles/evmlogger.log root 16399 1 0.0 14:03:54 ?? 0:00.12 /usr/sbin/syslogd -e root 16402 1 0.0 14:03:54 ?? 0:00.05 /usr/sbin/binlogd root 16431 1 0.0 14:03:56 ?? 0:00.02 /usr/sbin/routed -q root 16470 1 0.0 14:03:57 ?? 0:00.03 /usr/sbin/portmap root 16473 1 0.0 14:03:57 ?? 0:00.02 /usr/sbin/mountd -i root 16475 1 0.0 14:03:57 ?? 0:00.01 /usr/sbin/nfsd -t8 -u8 root 16478 1 0.0 14:03:57 ?? 0:00.00 /usr/sbin/nfsiod 7 root 16482 1 0.0 14:03:57 ?? 0:00.04 /usr/sbin/rpc.statd root 16484 1 0.0 14:03:58 ?? 0:00.07 /usr/sbin/rpc.lockd
4 11
UID root root root root root root root
Shutting Down and Rebooting the System
0:00.01 /usr/sbin/inetd 0:00.03 /usr/sbin/os_mibs 0:00.03 /usr/sbin/snmpd ?? 0:00.05 sendmail: accept -bd -q15m -om 2 root 16584 1 0.0 14:04:05 ?? 0:00.01 /usr/sbin/svrSystem_mib root 16589 1 0.0 14:04:05 ?? 0:00.02 /usr/sbin/svrMgt_mib root 16601 1 0.0 14:04:05 ?? 0:00.07 /usr/sbin/pmgrd root 16602 1 0.0 14:04:05 ?? 0:00.48 /usr/sbin/cpq_mibs root 16618 1 0.0 14:04:07 ?? 0:00.02 /usr/sbin/cpqthresh_mib root 16635 1 0.0 14:04:09 ?? 0:03.45 /usr/sbin/insightd root 16636 1 0.0 14:04:08 ?? 0:04.10 /usr/sbin/advfsd root 16641 1 0.0 14:04:12 ?? 0:01.71 /usr/sbin/config_hmmod root 16652 16520 0.0 14:04:14 ?? 0:00.10 -child (inetd) root 16658 1 0.0 14:04:15 ?? 0:00.05 /usr/sbin/cron root 16697 1 0.0 14:04:18 ?? 0:00.17 /usr/sbin/sysman_hmmod root 16699 1 0.0 14:04:18 ?? 0:00.04 /usr/lbin/lpd root 16711 1 0.0 14:04:19 ?? 0:00.58 /usr/dt/bin/dtlogin -daemon root 16749 1 0.0 14:04:23 ?? 0:03.30 /usr/bin/../opt/java118/bin/../bin/alpha/native_threads/java -mx2m authentication/server /AuthenticationServer root 16780 16711 0.1 14:04:27 ?? 0:04.92 /usr/bin/X11/X :0 auth /var dt/authdir/authfiles/A:0-aaefha root 16783 16711 0.0 14:04:31 ?? 0:00.11 dtlogin <:0> -daemon root 16785 1 0.0 14:04:33 ?? 0:14.67 /usr/sbin/smsd -d root 16814 16783 0.0 14:04:56 ?? 0:01.23 /usr/dt/bin/dtsession root 16858 1 0.0 14:05:07 ?? 0:00.20 /usr/dt/bin/ttsession -s root 16863 16652 0.0 14:05:08 ?? 0:00.53 rpc.ttdbserverd root 16876 16814 0.0 14:05:11 ?? 0:02.19 dtwm root 16880 16814 0.5 14:05:16 ?? 0:00.99 /usr/dt/bin/dtterm -session dtaad2oa -ls root 16883 16814 0.0 14:05:16 ?? 0:00.57 /usr/bin/X11/dxconsole root 16884 16814 0.0 14:05:16 ?? 0:02.25 dtfile -session dtaad2na root 16786 1 0.0 14:04:34 console 0:00.06 /usr/sbin/getty console console vt100 root 16885 16880 0.0 14:05:19 pts/1 0:00.13 -csh (csh) root 16887 16885 0.0 14:05:52 pts/1 0:00.07 ps -aef
root 16520 1 root 16541 1 root 16578 1 root 16581 1
0.0 14:04:14 ?? 0.0 14:04:05 ?? 0.0 14:04:02 ?? 0.0 14:04:03
Next, shut down the system to single-user mode and run the command again. The ps -aef command output in single-user mode might look like that shown in Example 4-2. Notice how few processes are running.
Example 4-2 Typical Single-User ps Output # ps -aef UID PID PPID C STIME TTY root 0 0 0.0 17:02:04 ?? root 1 0 0.0 17:02:04 ?? root 3 1 0.0 17:02:05 ?? root 5 1 0.0 17:02:05 ?? root 1520 1 0.0 17:10:45 console root 1522 1520 0.0 17:11:56 console # TIME CMD 0:20.13 [kernel idle] 0:00.25 /sbin/init -a 0:00.09 /sbin/kloadsrv 0:00.02 /sbin/hotswapd 0:00.02 - (sh) 0:00.05 ps -aef
4 12
Performing System Startup and Shutdown
Shutdown Log Files
Five minutes before shutdown (or immediately, if shutdown is in less than five minutes) the shutdown process creates the /etc/nologin_hostname file (or /etc/nologin in the case of a clusterwide shutdown) and copies the warningmessage and time of the shutdown to it. At shutdown time, the shutdown command writes a message to the system log. This message states the time of the shutdown, who ran the shutdown command, and the reason.
Complete Shutdown or Reboot
When used with the -h (halt) or -r (reboot) options, the shutdown command typically performs the following functions, in addition to the functions performed by the shutdown command when used with no options: Runs the sync command to synchronize the disks Unmounts the file systems Halts the processor The following command shuts down and halts the system at 10:30 PM:
# shutdown -h 2230 System shutdown tonight
If the command was shutdown -r, the shutdown command would automatically start a reboot operation to return the system to multiuser mode.
Using the halt Command to Stop the Processor
If you are working in single-user mode, you can stop the system by entering the halt command. The halt command: Logs the system halt in the event log and /var/adm/wtmp Kills running processes Synchronizes the disks Halts the processors
# halt syncing disks... done halting.... (transferring to monitor)
The halt is logged in /usr/adm/syslog.dated/date/auth.log.
Shutting Down with init
You can use the init command to change run levels. You can shut down the system from multiuser mode to single-user mode with either of the following commands:
init s init 1
You can also use the init command to halt the system. The format for the command is:
init 0
4 13
Shutting Down and Rebooting the System
The init command scans the /etc/inittab file to determine which commands and scripts to run. You would not normally use init to shut down the system or halt the system unless you have provided ample warning to the users with the wall command.
Other Methods of Shutting Down the System
Other methods for shutting down the system include: Entering the fasthalt command, which halts the system and flags the subsequent reboot not to carry out a file system consistency check (fsck). Sending the TERM signal (15) to the init process, which brings the system to single-user mode. Sending the KILL signal (9) to the init process, which may bring the system to console level.
Note These methods are not recommended for shutting down a system. The best way to shut down the system is with the shutdown command.
Rebooting the System
If you make changes to system software or configuration files that are executed only when the system is booted, you must reboot for these changes to take effect. Some devices, such as printers, can become unusable for unknown reasons and require resetting, which may not be possible without reinitializing the system. Under these circumstances, you may have to reboot the system.
Using the reboot Command
If you are working in single-user mode, you can safely shut down and automatically reboot your system to multiuser mode with the reboot command. The reboot command normally stops all processes, synchronizes the disks, logs the reboot, and writes a shutdown entry into the login accounting file. The reboot command does not provide a time delay, nor does it inform users of an impending shutdown and reboot. Do not use the reboot command if users are logged in; use the shutdown -r command instead. You must have root privileges to use the reboot command. See the reboot(8) reference page for a description of the command and its flags. If you are working in single-user mode, and do not need to check file systems, you can halt and reboot the systems with the fastboot command.
4 14
Performing System Startup and Shutdown
Shutting Down the System with CDE
Overview
The CDE Shutdown application (dxshutdown) provides a graphical user interface that you can use to shut down a system. This interface can also be invoked from the SysMan Station or the SysMan Menu. This application allows you to shut down a local or remote system from a windowing environment, a PC running Microsoft Windows or Windows NT, or from a terminal.
Invoking Shutdown
You can start the Shutdown application by choosing the Shutdown option from the General Tasks menu in the SysMan Menu. You can invoke the same interface from the SysMan Station. This option invokes a graphical interface if invoked from a windowing interface, or a character-cell interface if invoked from a terminal. You can start the Shutdown application by choosing the Shutdown icon in the CDE Application Manager, DailyAdmin options. If you are not logged in as root, the Shutdown application prompts for the root password. No further activity is permitted until you supply the password. The system displays the Shutdown window shown in Figure 4-2.
4 15
Shutting Down the System with CDE
Figure 4-2 Shutdown Window
Shutdown Options
The Shutdown window options provide the same functionality as the command line interface. Use the pull-down menu to choose one of the following shutdown types:
Halt Reboot Single-user Message only Halts the operating system and displays the console prompt Restarts the system Shuts down to the single-user command prompt Broadcasts a message to all current system users without shutting down the system
Move the slider bar in the Minutes until shutdown field to set the time before shut down begins. Type a message in the Shutdown message field to warn users of the impending shutdown and request that they log out. Check the Broadcast message to NFS clients box if you want the message to be broadcast to remote users of NFS-served file systems.
4 16
Performing System Startup and Shutdown
Check the Execute run-level transition scripts box to run the existing run-level transition scripts (for example, /sbin/rc0.d/K45.syslog). See the -s flag in the shutdown(8) reference page for more information. Specify a path in the Preshutdown Script field for a custom script that you want run before the shutdown completes. The script is run at shutdown time and will complete any tasks that you specify prior to shutting down the system. Note that if your script, or any intermediate scripts that it calls, do not complete successfully, the system may not shut down correctly. Check the Other options box to enable these options that make the shutdown faster:
Fast No disk sync Performs a fast shutdown, bypassing messages to users and NFS clients; bypasses fsck on the next boot Shuts down without synchronizing the disks
Shutdown Message Only
The Message Only option gives advance warning to users that the system will be shut down at a predetermined time for system maintenance. Since no shutdown will actually occur and only a message is sent to users, the time displayed has no impact.
Shutdown Reboot
Selecting this shutdown option causes a shutdown based on the time selected, followed by an automatic reboot.
4 17
Understanding Initialization Files
Understanding Initialization Files
Overview
When the system boots, the init process examines the /etc/inittab file. The init process executes the commands for any entry in the inittab file that corresponds to the run level. The superuser may execute the init command to cause a change in run levels (for example, init 2). In this case, the init command signals the init process, which scans the inittab file and executes entries that contain the specified run level. Entries containing the boot or bootwait action fields are not executed. Of course, if you are shutting the system down or changing the run level to one that excludes the normal user, you should use the wall command to warn users.
Initialization Files
The following files and directories are used to boot or change run levels: The /etc/inittab file is the first file looked at by init. It designates the scripts or programs to execute for a change in run level. The /sbin/rc0, /sbin/rc2, or /sbin/rc3 run command scripts are used to control the change to run level 0, S, 2, or 3. The /sbin/rc0.d, /sbin/rc2.d, or /sbin/rc3.d directories contain links to the scripts or programs to be run to change to run level 0, S, 2, or 3. The script /sbin/rc0 uses the directory /sbin/rc0.d, while /sbin/rc2 uses the directory /sbin/rc2.d, and /sbin/rc3 uses the directory /sbin/rc3.d. The /sbin/init.d directory contains executable files associated with system startup and the available run levels.
Changing Run Levels
Before changing to a new run level, check the inittab file to confirm that the run level to which you intend to change supports the processes you need. Of particular importance is the getty process because it controls the terminal line access for the console and other logins. Make sure that the getty entry in the inittab file allows system console access at all run levels. Refer to the inittab(4) reference page for more information about defining run levels. Refer to the getty(8) reference page for more information about defining terminal lines and access. Before changing to a new run level, use the wall or write command to warn users that you intend to change the run level. Because a change in run level could result in termination of a user's getty process (which disables their login capability) as well as the termination of other processes that the user is running, you should communicate the change to each logged-in user. Check the getty entry for user terminals to verify that the new run level is specified in the entry. If it is not, request that users log off so that their processes will not terminate in response to a kill signal from init. When the system is initialized for the first time,
4 18
Performing System Startup and Shutdown
it enters the default run level that is defined by the initdefault line entry in the inittab file. The system continues at that run level until init receives a signal to change run levels. This figure describes the use of the initialization files to change to run level 2.
Figure 4-3 Initialization Files
/etc/inittab is:3:initdefault: . . . s2:23:wait:/sbin/rc2 \ < /dev/console \ > /dev/console 2>&1 /sbin rc0 rc2 rc3 /sbin/rc2.d K05inet ../init.d/inet .. . S25enlogin ../init.d/enlogin /sbin/init.d inet . . . enlogin
sm0304
This figure shows that the command "/sbin/rc2 < /dev/console > /dev/console 2>&1" is used. Standard input, standard output, and standard error are all directed to the console. There are other commands in the /etc/inittab file that are not shown that would run prior to this command. Those entries with the boot or bootwait action fields are executed first, then the remaining entries for the pertinent run level are executed. The shell script file rc2 (/sbin/rc2) is executed. This script checks to see if this is a boot (previous run level was single user) or if it is a change in run level. In either case, the link files in /sbin/rc2.d cause the files in /sbin/init.d to run. If you are booting, all files with an S as the first letter in the file name are executed. The S indicates start. If you change from run level 3 to run level 2, all files with a K as the first letter in the file name are executed. The K indicates kill. If there is a change from run level 3 to run level 2, there are daemons that have to be stopped (no network services in run level 2). If you change from run level 3 to run level 2, once the files with names beginning with K have been run, all /sbin/rc2.d files with names beginning with S are then executed. In the previous figure, the link K05inet --> ../init.d/inet causes the execution of /sbin/init.d/inet, which is just one of the commands used to stop the network processes. The link S25enlogin --> ../init.d/enlogin causes the execution of /sbin/init.d/enlogin, which will enable logins.
The inittab File
One of the first actions taken by the init program is to read the /etc/inittab file. The inittab file supplies the init program with instructions for creating and running initialization processes. The init program reads the inittab file each time init is invoked. The file typically contains instruction for the default initialization, the creation and control of processes at each run level, and the getty line process that controls the activation of terminal lines.
4 19
Understanding Initialization Files
The format for the entries in the /etc/inittab file is:
ID:run-levels:action:process
ID run-levels action process A 14-character string used to identify the entry Number of one or more run levels How to handle the process field Script file or command to execute
The fields in each entry are separated by colons (:). The ID field in the entry may be null. If the run-level field is null, the entry is valid for all run levels. If the field is null, the colon must still be present. Comment lines begin with a number sign (#). Table 4-3 describes the action fields.
Table 4-4 The inittab File Action Field
Action Description
Run when the system transfers to the specified run level from a lower level for the first time (that is, during booting). The init process starts the process but does not wait for its termination. Run when inittab is read for the first time. The init process starts the process and waits for its termination. If the process terminates, it is not restarted. Specifies the default run level. If more than one number is in the run-level field, the highest run level is used. If the process is currently running, the init process sends SIGTERM, waits 20 seconds, then sends the kill signal, SIGKILL. If the process does not exist, init ignores the entry. The init process starts the process but does not wait for its termination. When the process stops, it is not restarted. If the init process receives the SIGPWR powerfail signal, the process is executed. If the init process receives the SIGPWR powerfail signal, it executes the process and waits for the process to terminate before resuming processing of the inittab file. If the process does not exist or if the process terminates, init restarts the process. Executed before init tries to access the console. The init process starts the process and waits for it to terminate. The init process will not handle any other inittab entries until the process terminates.
boot bootwait initdefault off once powerfail powerwait respawn sysinit wait
For a boot, the init process searches the inittab file for the line containing the action entry of initdefault. During booting, init processes the entries with action fields of boot or bootwait for the defined run level before processing other entries for the run level. For other changes in run levels, init searches for any entries which contain the new run level.
4 20
Performing System Startup and Shutdown
Sample inittab File
The operating system provides you with a basic /etc/inittab file that contains line entries for the most common and necessary initialization processes. A sample inittab file is shown in the following example.
Example 4-3 A Typical inittab File # cat /etc/inittab is:3:initdefault: ss:Ss:wait:/sbin/rc0 shutdown < /dev/console > /dev/console 2>&1 s0:0:wait:/sbin/rc0 off < /dev/console > /dev/console 2>&1 lsmr:s:sysinit:/sbin/lsmbstartup -b /dev/console 2>&1 ##LSM lsm:23:wait:/sbin/lsmbstartup /dev/console 2>&1 ##LSM vol:23:wait:/sbin/vol-reconfig -n /dev/console 2>&1 ##LSM fs:23:wait:/sbin/bcheckrc < /dev/console > /dev/console 2>&1 kls:Ss:sysinit:/sbin/kloadsrv < /dev/console > /dev/console 2>&1 hsd:Ss:sysinit:/sbin/hotswapd < /dev/console > /dev/console 2>&1 sysconfig:23:wait:/sbin/init.d/autosysconfig start < /dev/console > /dev/console 2>&1 update:23:wait:/sbin/update > /dev/console 2>&1 smsync:23:wait:/sbin/sysconfig -r vfs smoothsync-age=30 > /dev/null 2>&1 smsyncS:Ss:wait:/sbin/sysconfig -r vfs smoothsync-age=0 > /dev/null 2>&1 it:23:wait:/sbin/it < /dev/console > /dev/console 2>&1 kmk:3:bootwait:/sbin/kmknod > /dev/console 2>&1 s2:23:wait:/sbin/rc2 < /dev/console > /dev/console 2>&1 s3:3:wait:/sbin/rc3 < /dev/console > /dev/console 2>&1 cons:1234:respawn:/usr/sbin/getty console console vt100 #
Here is an explanation of some of the entries.
is:3:initdefault -- The init process uses this entry to determine the default run
level (in this case, 3).
ss:Ss:wait:/sbin/rc0 shutdown -- For a change to single-user mode, the init process executes the rc0 script with "shutdown" as the input argument. It waits until the rc0 script completes execution before executing any other commands. s0:0:wait:/sbin/rc0 off -- For a change to the halt state, the init process executes the rc0 script with "off" as the input argument. It waits until the rc0 script
completes execution before executing any other commands.
fs:23:wait:/sbin/bcheckrc -- For a change to run levels 2 or 3, the init process executes the bcheckrc script to check and mount file systems. (The bcheckrc command skips the check if the fastboot file exists.) It waits for the script
to terminate, but does not restart it.
it:23:wait:/sbin/it -- For a change to run levels 2 or 3, the init process runs the it script to make sure the system is configured. kmk:3:bootwait:/sbin/kmknod -- When the system boots, the init process executes the kmknod script to create device special files for kernel layered products. s2:23:wait:/sbin/rc2 -- For a change to run level 2 or 3, the init process starts the rc2 script, and waits for it to terminate.
4 21
Understanding Initialization Files
s3:3:wait:/sbin/rc3 -- For a change to run level 3, the init process starts the rc3 script, and waits for it to terminate. cons:1234:respawn:/usr/sbin/getty -- For a change to any run level (other than halt), the init process invokes the getty program, which sets the terminal line attributes for the system console. If the getty process terminates, it is re-created.
Supporting Terminals To enable user logins at terminals on your system, you must define the run level and getty process for each supported terminal type. The /usr/lib/terminfo database contains entries that describe each terminal type and it