Notes for Week 5

  1. The startup process on our distribution of Linux uses "sysvinit". It has been modified to permit operation from DVD-ROM. In sysvinit, the runlevel defines which daemons and services are operating on the system at any point in time. A default runlevel is specified in /etc/inittab, and runlevels may be switched using the telinit command.

    There are seven runlevels numbered 0 through 6, five of which have fairly well-defined uses:

    On our system, runlevels 3 and 5 are identical and runlevel 2 does not include networking or gpm. Runlevel 4 will be used to run servers later in the course (and for experimentation below).

    The services which are run for each runlevel are specified in directories /etc/rc.d/rc#.d/, where "#" is the runlevel. The "files" in the runlevel directory are symbolic links to scripts in /etc/rc.d/init.d. The names are of the form "Snndaemon" or "Knndaemon", where S means start this daemon in this runlevel, and K means kill this daemon before starting this runlevel, and nn is a number used to order the kills and starts. When a runlevel is started, the kill scripts are run in alphabetical order, and then the start scripts are run, also in alphabetical order.

    When booting, init first runs the scripts in /etc/rc.d/rcS.d. For our system, these:

    init then runs the scripts for the specific runlevel as described above. For instance, in runlevel 3, they:

    The above init strategy makes it particularly easy to restart services: one simply re-runs the script. For example, to change the IP address, the system administrator need only modify the correct configuration files and run /etc/rc.d/init.d/network restart. Rebooting should never be necessary, except if a different kernel needs to be run, an extremely rare kernel panic occurs, or a power failure occurs.

    A limited ability to tailor the startup of Windows is available through the msconfig command.
    Note that some of the startup scripts log to /var/log/boot.log and not to /var/log/sys.log.

  2. inittab is usually not modified except to change the default runlevel or to specify how "Ctrl-Alt-Delete" is processed, what happens when power failure and power restored signals are received from a UPS (Uninterruptible Power Supply) and how many virtual consoles are started.

  3. At shutdown, the daemons are stopped in essentially the reverse order in which they were started. After the external network interfaces are brought down, signals are sent to all remaining processes: first the TERM signal, then the KILL signal. Swap partitions are deactivated and filesystems are unmounted. Finally, the loopback interface is brought down and the system rebooted or shutdown, depending on the runlevel.

  4. There is a great deal of variation in startup between various Linux distributions, not to mention other UNIX flavors. This is natural, since the character of a running system is largely dictated by what happens at boot time: modifying the startup scripts is an important way for the distribution designer, as well as the system administrator, to control the behavior of the system.

    System administrators often put all of their local modifications in a single script, which is usually run just before init starts the agetty processes. To do this, one could create the script /etc/rc.d/init.d/local and then link it to the appropriate run level directories using, for instance, ln -s /etc/rc.d/init.d/local /etc/rc.d/rc3.d/S99local.

  5. UNIX uses a number of text files for system configuration purposes, almost all of which reside in /etc (or a subdirectory thereof).
    Windows uses the "registry" to hold configuration information, but it is nearly impossible to modify it in a "safe" way other than through control panels which do much to hide the workings of the system from the curious. Registry failure is generally a catastrophic event, while text file failure only affects the particular file involved.

    When booting from the DVD-ROM, our distribution interactively prompted you to configure the following files (from /etc/rc.d/init.d/netconfigure):

    If you think you're having trouble with a network device, the ifconfig command will display error counts. The more serious of these will also be in the log file, of course.

  6. In week 2 you modified /etc/fstab. Note that the option "user" on the /media/usbstg line indicates that an ordinary user (not root) can mount disks on the device (see mount options in the man page).

    A common technique is to use symbolic links for devices for increased flexibility. For instance, you could link /dev/flash to /dev/sdc1 with ln -s /dev/sdc1 /dev/flash and change the /media/usbstg line's device entry from /dev/sdc1 to /dev/flash. By using a symbolic link in fstab instead of a specific device, changes in hardware configuration will not require another change in fstab (or in any scripts); simply delete the old /dev/flash link and make a new one as appropriate. Other common links are /dev/cdrom and /dev/dvd.

  7. In week 2 you also modified /boot/grub/grub.cfg on /dev/sdb5.

  8. Other configuration files which were set up during the design of the DVD-ROM:

  9. There are many other configuration files which have not been altered from their released versions. Most of these are in /etc, and many of them have comments (lines beginning with "#") which explain the configuration parameters in detail. Many of them are also documented in section 5 of the man pages. Note that you must be root to modify anything in /etc.

  10. Most configuration files must end with a newline character, so that the last line of the configuration is recognized as complete. Shell scripts also benefit from an ending newline.

  11. EXERCISES for Week 5:

    1. Use telinit 1 to change to single user mode.
      Do all of your telinits at the command line, while X-windows is not running. Otherwise, you will not see everything you are supposed to see.
      Examine your path, the working directory and the processes currently running. Submit your results to the instructor (include only non-kernel processes).
      An easy way to save the results of your investigations is to append them to a text file using the syntax
      command >> file.txt
      If file.txt does not exist, it will be created, and each subsequent command used this way will append its output to the file.

    2. Change the startup order in runlevel 4 for ntpd and dbus, but do not change their startup order relative to any other script. telinit to runlevel 4. What happens?

    3. Change the startup order so that dbus is the last thing to start before entering a specific runlevel. Reboot. What happens?

      Telinit to runlevel 4.

    4. Create a local startup script as described above, and use it to display a welcome banner (in plain text, of course). Test it by teliniting to runlevel 3. Now what happens?
      Writing a script is easier than you might think. Open emacs and type #!/bin/sh and push the Enter key. This tells the system that you want to use bash to process this script. If you know Perl or Ruby or Python, you could write a script in those languages as well, and the sh-bang line would be "#!/usr/bin/perl", or etc.

      Next open an xterm window and test the first command you want in your script. In this case it might be an "echo" command to display some text output (Windows also supports echo). When it does what you want it to, copy and paste the final version of the command into the emacs window and press Enter again.

      Continue in this way until your script is complete. Save the script, in this case as /etc/rc.d/init.d/local, and then enter the command chmod 744 /etc/rc.d/init.d/local to allow the shell to execute it as a script. (More about this next week.)

      You can now test the script by typing its name (/etc/rc.d/init.d/local) at the command prompt.

      This process should also work in Windows, except that the sh-bang and chmod are not necessary. The sh-bang is really not necessary in Linux, as long as you want bash to run the script.
      Finally, link it to the startup directory using the command ln -s /etc/rc.d/init.d/local /etc/rc.d/rc3.d/S99local. When you telinit 3 from runlevel 4, or during startup, your script should execute automatically.
      When you do that, do you notice anything odd?

©2015, Kenneth R. Koehler. All Rights Reserved. This document may be freely reproduced provided that this copyright notice is included.

Please send comments or suggestions to the author.