Booting and shutting down
Booting
Startup Scripts
Rebooting and shutting down
Reading: Chapter 2, Booting and Shutting Down
- Loading the OS into memory and getting it running is called "bootstrapping" (from the expression "pulling yourself up by your bootstraps"), often simply called "booting"
- Exactly what happens is hardware dependant
- But we'll try to stay fairly generic here
- The boot process can be fairly complex, and understanding it fully requires quite a bit of knowledge of how Unix works
- This also means that understanding the boot process helps with understanding Unix in general
- In the boot process you first see the Unix philosophy of having many small programs, each of which does a specific job, rather than having one large program which attempts to do everything
- Scripts that handle startup are often generically referred to as "rc files," and many have the letters "rc" in the name
- "Automatic" vs. "Manual" booting
- Automatic: system bootstraps itself, and comes up running normally (often called "multiuser mode")
- This is probably what you want for the default
- Manual: you intervene, and tell the system to load a different kernel, or come up in "single-user mode," which may be necessary to fix certain problems
- Because Unix is a complex operating system, there is a lot of complexity in getting it started
- Load kernel (the piece of code that controls everything else)
- Hardware specific
- Usually there is some sort of ROM, EEPROM, or non-volaitle RAM, which knows how to load the kernel
- To do this, it needs to know how to read the filesystem and talk to the disk
- There's usually a user-configurable setting of what disk and/or partition to boot off of
- Perhaps also a pre-defined sequence
- e.g. Check SCSI devices, from lowest number to highest, if the boot disk isn't defined or doesn't exist
- Usually possible to intervene and load different kernels
- Useful for debugging, or recovering from a bad kernel mod/upgrade
- Scan hardware
- Next, the kernel scans the hardware, checking the amount of RAM, and seeing what devices are attached
- May do some initialization and load or disable device drivers
- Start processes
- Spontaneous processes
- Not created using fork(), like all other Unix processes
- We'll discuss fork when we talk about processes later
- Varies by type of system
- BSD
- swapper, Process ID 0
- init, Process ID 1
- pagedaemon, Process ID 2
- System V
- sched, Process ID 0
- init, Process ID 1
- various memory and kernel handlers, depends on particular OS
- Linux
- There is no Process ID 0
- init, Process ID 1
- Various memory and kernel handlers (kflushd, kupdate, kswapd, etc.)
- Most important is init
- The only one that's really a process
- Starts up everything else on the system
- We'll learn more about init when we discuss processes
- The others are actually parts of the kernel made to look like a process
- If the boot was into "single-user mode", things stop at this point, and a command shell is started so that you may do whatever you need to do
- Run initialization scripts
- Set system name
- Check and mount disks
- Clean out tmp directories
- Configure the network interface
- Start various system services
- Check/set the time
- Exact location of the scripts, and exactly what is done in the scripts is vendor-specific, but there are two main ways that things are organized
- BSD
- System V
- More on startup scripts in a little bit
- Booting PCs
- The book talks a bit about booting PC architectures. (Because, unfortunately, it's a lot more complex than booting propietary architecutres) This is good background reading, but we won't spend time on it in lecture.
- The book also gives specifics for booting into single user mode for each of the 4 example OSes. How to do it is specific to each OS. You should know how to do it on whatever you're administering, because you'll probably have to do it someday.
- If the system won't boot
- Check that everything is connected and plugged in!
- Try booting in single-user mode
- Try booting a different kernel (you should always have an alternate, known-to-be-working kernel!)
- Try booting from a different disk (if possible)
- Try booting from the installation media (usually a CD-ROM)
- If all else fails, call the vendor. You probably have a hardware problem. This is what support contracts are for.
- Once upon a time, you configured startup behavior of a Unix system by editing the startup scripts.
- These days, the scripts probably read one or more configuration files to set parameters that affect their behavior. You should modify these configuration files, rather than the scripts.
- There are two basic startup methodologies
- BSD
- If coming up in multiuser mode, init will run various scripts in the /etc directory, probably all of which start with the letters "rc".
- System V
- System V has several "run levels"
- Various things happen at various run levels
- For example, Red Hat defines run level 3 to be multiuser without a GUI running, and run level 5 to be multiuser with a GUI.
- Special run levels are
- 0 -- halted
- 1 (or S) -- single user
- 6 -- reboot
- /etc/inittab defines the run levels and what happens in them
- Also defines a "default" run level
- AIX stops here. Most other systems have a directory structure of startup scripts.
- init.d
- Location of these directories varies. It might be in /etc. It might be in /sbin. On Red Hat, they're in /etc/rc.d.
- Contains the actual startup scripts, which should understand arguments of "start", "stop" and maybe others
- rc?.d
- e.g. rc1.d, rc2.d, etc.
- Contains soft links to the scripts in init.d
- If the filename starts with "S", will call the script with the argument "start"
- If the filename starts with "K", will call the script with the argument "stop"
- "Starts" happen when moving to higher levels; "kills" happen when moving to lower levels
- Some systems run all intervening levels, some don't
- For example, when moving from run level 2 to run level 5, some systems will only run the "S" scripts in rc5.d, while some systems will run all the "S" scripts in rc3.d, rc4.d, and rc5.d.
- The book discusses the specifics of the startup scripts in each of the four example systems. Again, this is good reading, but not something we'll spend time on in class. (Look for it in lab, though.)
- Because Unix keeps some file information buffered in memory, and flushes it out periodically (called "syncing the disks"), it is important to shut down the system gracefully
- Failing to shut down gracefully can cause file system corruption and lead to lost data or even an unbootable system
- Some newer filesystems are making this better, but you still need to be careful
- Reboots are usually less frequent in Unix than in other OSes
- And more costly
- And may not solve the problem
- Hence, the book's advice to "think first, reboot second"
- Almost al Unix variants are working to reduce the need for reboots
- e.g. "kernel modules" which can be loaded and unloaded while running have become popular, replacing the need to reboot whenever anything needed to change in the kernel
- Many ways to shut down
- Turn off power
- Don't do this, unless it's an emergency
- shutdown command
- Has several options -- can shut down compeletely, reboot, or bring the system down to single-user mode
- Specifics tend to be vendor-specific
- halt command
- Shuts the system down completely, but without doing all the same work that shutdown does (but does do a sync)
- reboot
- Reboots the system, but without doing all the same work that shutdown -r does (but does do a sync)
- send the init process a TERM signal (kill -TERM 1)
- Some versions of Unix have a version of init that prevents you from doing this
- telinit
- Made for changing run levels
- Can be used to shut down to single-user mode
Part of the CptS 302 Website
Instructor:
Geoff Allen
,
geoff@wsu.edu
Source Modified: Tue Aug 28 20:54:38 2001
HTML Generated by WML 2.0.6 (25-Oct-2000): Tue Aug 28 21:01:32 2001
Disclaimer