Startup and Shutdown

A booting overview

1. The process by which a computer is turned on and the UNIX operating system starts functioning – booting – consists of the following steps

1. finding the kernel
2. starting the kernel
3. starting the processes

Finding the kernel

1. The kernel is the heart of the UNIX operating system. The kernel provides a number of essential services, which are required by the rest of the system in order for it to be functional. The first step is finding the kernel.

ROM

1. Most computers have a section of read only memory (ROM) that contains a program the machine executes when the power first comes on.
2. On an IBM PC, the ROM program does some hardware checks and then looks in a number of predefined locations (the first floppy and the primary hard drive partition) for a bootstrap program.
3. On hardware designed for the UNIX operating system (machines from SUN, DEC, IBM, HP, etc.), the ROM program is more complex than that of a PC. Many will present some type of prompt. This prompt generally accepts a number of commands that allow the administrator to specify

1. Where to boot the machine from. This can be a local CD-ROM, a Hard Drive, or network server.
2. perform system tests
3. boot to single user or multi-user mode

1. The ROM must be smart enough to find the bootstrap program.

The bootstrap program

1. The code stored in the boot block  is referred to as a bootstrap program.
2. The boot block is not large enough to hold the kernel, so this intermediate stage is necessary.
3. The bootstrap program is responsible for locating and loading (starting) the kernel of the UNIX operating system into memory.
4. The kernel of most UNIX operating systems is stored in the root directory of the filesystem.
5. Under Red Hat Linux, the kernel is stored in /boot.
6. The most common bootstrap program in Linux is called LILO.

Boot on a PC

1. The BIOS on a PC contains

1. a program that performs a power on self test (POST) each time it is powered on.
2. a program called SETUP, which allows the user to configured certain hardware components of the computer. Pressing the “DEL” or “F2” keys on the keyboard enters the SETUP program.

1. The BIOS generally looks for a bootstrap program in this order

1. the first floppy drive ( A: )
2. the first partition on the first hard drive ( C: )
3. the first CD-ROM drive

1. Most modern computers allow users to change the boot sequence via the SETUP program.
2. The bootstrap program is stored on the first sector of the boot device.
3. The bootstrap program is loaded into memory and executed. It then loads the kernel into memory.

Making a boot disk under Linux (manually)

1. Insert a floppy disk into a computer already running Linux
2. Login as root
3. change into the /boot directory
4. copy the kernel onto the floppy: dd if=vmlinux of=/dev/fd0

Note: The kernel name may contain a version number. For example, the kernel name could be vmlinux-2.0.31.

1. Tell the boot disk where to find the root disk: rdev /dev/fd0 /dev/hda6 (make sure this points to the Linux boot partition)

mkbootdisk command

1. Easiest way to create a self contained boot diskette for your system.
2. Gives you the “rescue” option at the boot prompt. This option gives you the ability to create a system in RAM and mount your hard drives so you can modify them.

Using a boot loader

1. Having a boot floppy for your system is a good idea.  It can save you if your system will not boot from the hard drive.
2. The steps listed above will not work with a hard drive. A boot loader, such as LILO, is needed.
3. A boot loader generally examples the partition table of the hard drive, identifies the active partition, and then reads and starts the code in the boot sector for that partition.
4. Other features offered by LILO

1. using a key to bring up a prompt to modify the boot procedure, and
2. the passing of parameters to the kernel to modify its operation

LILO – Linux Loader

1. LILO is the boot loader (or boot manager) used in most Linux systems.
2. LILO allows the user to select from multiple operating systems to boot (dual boot)
3. The LILO configuration file is /etc/lilo.conf.
4. You must execute the LILO command after making changes to the configuration file. This will update LILO with the changes made.
5. To uninstall LILO and restore the previous master boot record (MBR), issue the command: lilo –u
6. To prevent someone from booting your Linux system in Single User Mode without specifying a password:

1. Edit /etc/lilo.conf
2. add the option: password=clear_text_password:
3. add the option: restricted:
4. Save the changes
5. change permissions on the file so only root has read and write permissions. (chmod 600 /etc/lilo.conf)
6. execute `lilo` to update changes

Starting the kernel

1. The kernel will go through the following process
2. Swapper is a part of the kernel and therefore is not a real process.
3. The init process is the parent of all processes that will execute on a UNIX system.
4. Once the kernel has initialized itself, init will perform the remainder of the startup procedure.

1. initialize its internal data structures
2. check for hardware connected to your system  ( Note: the kernel only looks for hardware that it contains code for. )
3. verify the integrity of the root file system and then mount it
4. create the process 0 (swapper) and process 1 (init)

Kernel boot messages

1. When a UNIX kernel is booting, it will display messages on the main console about what it is doing.
2. Under Linux, these messages are sent to syslog and are by default appended to the file /var/log/messages.
3. You may find the file /var/log/dmesg, which also contains a copy of the boot messages.

Starting the processes

1. An existing process performing a fork operation creates processes.
2. init is the ancestor of all processes on a UNIX system.
3. It always has a process ID (PID) of 1.
4. init is responsible for starting all other services.
5. The services to be started is specified in init’s configuration file, /etc/inittab.

Run Levels

1. init is responsible for placing the computer into one of a number of run levels.
2. The run level controls what services are started or stopped by init.
3. When a Linux system boots, init examines the /etc/inittab file for an entry of type initdefault. This entry will determine the initial run level of the system.

1. Under Linux, the telinit command is used to change the current run level.  The init command is also used for the same purpose.
2. telinit is actually a soft link to init.

1. telinit or init accept a single character argument from the following

1. The run level to switch to: 0 1 2 3 4 5 6
2. Tells init that there has been a change to /etc/inittab and that it should re-examine it: Q or q
3. Tell init to switch to single user mode: S or s

/etc/inittab

1. /etc/inittab is the configuration file for init. It is a colon delimted field where # characters can be used to indicate comments.
2. The fields of /etc/inittab:

1. the identifier: one or two characters to uniquely identify the entry
2. the run level: indicates the run level at which the process should be executed
3. the action: tells init how to execute the process
4. the process: the full path of the program or shell script to execute

What happens

1. When init is first started, it determines the default run level by matching the entry in /etc/inittab with the action initdefault.

The identifier

1. The first field is a unique identifier.
2. For inittab entries that correspond to terminals the identifier will be the suffix for the terminals device file.
3. For each terminal, a getty process must be started by the init process.
4. Each terminal will have a name like /dev/tty??. Where ?? will be replaced by a suffix. It is this suffix that must be the identifier in the /etc/inittab file.

Run Levels

1. The run levels describe at which run levels the specified action will be performed. For example, it the field contains 123, then the action will be performed in levels 1, 2, and 3.

Actions

1. This field describes how the process will be executed.

An example /etc/inittab configuration file

#

# inittab       This file describes how the INIT process should set up

#               the system in a certain run-level.

#

# Author:       Miquel van Smoorenburg, <[email protected]>

#               Modified for RHS Linux by Marc Ewing and Donnie Barnes

# Default runlevel. The runlevels used by RHS are:

#   0 – halt (Do NOT set initdefault to this)

#   1 – Single user mode

#   2 – Multiuser, without NFS (The same as 3, if you do not have networking)

#   3 – Full multiuser mode

#   4 – unused

#   5 – X11

#   6 – reboot (Do NOT set initdefault to this)

#

id:3:initdefault:

# System initialization.

si::sysinit:/etc/rc.d/rc.sysinit

l0:0:wait:/etc/rc.d/rc 0

l1:1:wait:/etc/rc.d/rc 1

l2:2:wait:/etc/rc.d/rc 2

l3:3:wait:/etc/rc.d/rc 3

l4:4:wait:/etc/rc.d/rc 4

l5:5:wait:/etc/rc.d/rc 5

l6:6:wait:/etc/rc.d/rc 6

# Things to run in every runlevel.

ud::once:/sbin/update

# Trap CTRL-ALT-DELETE

ca::ctrlaltdel:/sbin/shutdown -t3 -r now

# When our UPS tells us power has failed, assume we have a few minutes

# of power left.  Schedule a shutdown for 2 minutes from now.

# This does, of course, assume you have powerd installed and your

# UPS connected and working correctly.

pf::powerfail:/sbin/shutdown -f -h +2 “Power Failure; System Shutting Down”

# If power was restored before the shutdown kicked in, cancel it.

pr:12345:powerokwait:/sbin/shutdown -c “Power Restored; Shutdown Cancelled”

# Run gettys in standard runlevels

1:12345:respawn:/sbin/mingetty tty1

2:2345:respawn:/sbin/mingetty tty2

3:2345:respawn:/sbin/mingetty tty3

4:2345:respawn:/sbin/mingetty tty4

5:2345:respawn:/sbin/mingetty tty5

6:2345:respawn:/sbin/mingetty tty6

# Run xdm in runlevel 5

x:5:respawn:/usr/bin/X11/xdm -nodaemon

The process

1. Is simply the absolute path to the command or script that should be executed by init.

Daemons and configuration files

1. init is an example of a daemon. It will only read its configuration file, /etc/inittab, when it starts execution.  Any changes you make to the configuration file will be read the next time the daemon is started or when you force init to re-read the configuration file.
2. One way to tell a daemon to re-examine its configuration file is to send a HUP signal to the daemon. The first step is using the `ps` command to find the process ID (PID) of the daemon. Then use the `kill` command to send a HUP signal to the daemon. init is easy because it will always have a PID of 1.

kill –1 1         or kill HUP 1        -sends the HUP signal to init

1. The most common way for tell init to re-examine its configuration file is using the `telinit Q` command.

System Configuration

1. There are a number of tasks, which must be completed in order to configure the system for operation. Most of these tasks are performed by the /etc/rc.d/rc.sysinit script.
2. This script performs the following operations

1. sets up a search path that will be used by the other scripts
2. obtains network configuration data
3. activates the swap partitions of your system
4. sets the hostname of your system
5. sets the machine’s NIS domain ( if in use )
6. performs a check on the file systems of your system
7. turns on disk quotas (if being used)
8. sets up plug and play support
9. deletes old lock and tmp files
10. sets the system clock
11. loads any kernel modules

Terminal logins

1. On Red Hat systems, a mingetty process is started for virtual console logins.

Startup scripts

1. The system startup scripts are shell scripts written using the Bourne Shell. Each run level executes /etc/rc.d/rc. The run level is passed to this script as an argument.
2. In the UNIX world there is two styles for startup files: BSD and System V. Red Hat uses the System V style.

The Linux process

1. When init first enters a run level it will execute the script /etc/rc.d/rc. This script proceeds to

1. determine the current and previous run level
2. kill any services which must be killed
3. start all the services for the new run level

1. /etc/rc.d/rc knows how to start or kill services for a run level because of the name in the directory for each run level.
2. Filenames in each directory use the same format: [SK]numberService

1. where number is some integer and Service is the name of a service
2. All files beginning with S are used to start a service.
3. All files beginning with K are used to kill a service.
4. The numbers in the filenames are used to indicate the order in which these services should be started or killed.
5. The filenames in each rcX.d directory are nothing more than soft links to scripts stored in /etc/rc.d/init.d

Starting and stopping

1. Scripts in /etc/rc.d/init.d are useful when you are performing maintenance on your system. Use them to start and stop services while you are working on them.
2. For example: to stop the web server:

$ /etc/rc.d/init.d/httpd stop       Stops the web server daemon

$ /etc/rc.d/init.d/httpd start      Starts the web server

1. No need to reboot your system to reconfigure most services. Simply stop the service, edit the configuration file(s), and restart the service.

Lock files

1. Scripts that start services during system start up create lock files. These files, if they exist, indicate that a service is operating and prevents the system from starting a service, which is already running.

Shutting down

1. Never turn off a UNIX system by pressing the power button. During so can cause damage to the file system or corrupt data.
2. If the system is not shutdown correctly, the system will be forced to perform a detailed check of the file systems.  You may be forced into single user mode if the check fails. Then you must run the `fsck` command to repair the file disk and then reboot.

1. Tasks to be completed for a UNIX system to shutdown cleanly

1. tell users the system is going down. Give them enough time to save their work and log out.
2. Signal the currently executing processes that it is time for them to die.
3. place the system into single user mode
4. performs `sync` to flush the file systems buffers so that the physical state of the file system matches the logical state.

Reasons for Shutting down

1. Limit the number of times you turn a computer on or off as doing so causes wear and tear. it is better to leave a system on 24 hours a day, 365 days a year.
2. Some reasons for shutting down a UNIX system

1. General housekeeping – every reboot causes the system to delete files from the temporary directories and perform checks on the machines file systems. Rebooting also get rid of any zombie processes. Zombie processes are those that you killed but would not die.
2. general failures – Problems may arise for which you have only one resort, reboot the system.  These problems include hanging logins, unsuccessful mounts requests, dazed devices, runaway processes filling up disk space or CPU time and preventing any useful work being done.
3. System maintenance and additions – Some work require the machine to be turned off. For example, replacing a failed hard disk or adding a network interface card (NIC).

Being nice to users

1. The shutdown command can be used to initiate a system shutdown and notify users. You can schedule a time for the shutdown to occur.

1. When using shutdown, a message is sent to all users informing them that the system is going down.

1. System shutdown must be scheduled. System maintenance should be performed during scheduled down time. Keep the system running as much as possible. Take it down only when necessary.

1. Edit /etc/motd (Message Of The Day) to add any messages you want all users to see upon logging into the system. Schedule down times can be added to the file.

Commands to shutdown

1. shutdown – most used, can send messages to users indicating the system is going down. These messages are repeated at preset intervals until the time to shutdown has been reached.
2. halt – logs the shutdown, kills the system processes, executes sync and halts the system.
3. reboot – similar to halt, but causes the system to reboot.
4. sending a term signal to init – ` kill –15 1` will cause init to change run levels to single user mode. Not a safe method of shutting down the system.
5. the fasthalt or fastboot commands – These commands create a file /fastboot before calling halt or reboot. The /fastboot file causes the system to skip the testing of the file systems on reboot.

Shutdown

Options:

1. –h : Halts the system
2. –r : reboot the system
3. –f  : do a fast boot
4. –q : use a default broadcast message
5. –s : reboot to single user mode
6. –k : fake shutdown, sends messages, but never takes the system down.
7. –c : cancel a running shutdown

The time at which a shutdown will occur are specified by the following options

1. now – shutdown immediately
2. hh:ss – shutdown at the time specified
3. +mins – shutdown mins from now

1. What happens

1. five minutes before shutdown or straightway if shutdown is less than 5 mins, the file /etc/nologin is created to prevent users to log on the system.
2. At shutdown time, all users are notified, init is told not to spawn any more getty processes. Shutdown time is written in /var/log/wtmp. All processes are kill. A sync is performed, all file systems are unmounted, another sync is performed, and the system is rebooted.

1. Only use halt and reboot when no one is logged on the system.