|Home||Switchboard||Unix Administration||Red Hat||TCP/IP Networks||Neoliberalism||Toxic Managers|
May the source be with you, but remember the KISS principle ;-)
Skepticism and critical thinking is not panacea, but can help to understand the world better
|Recommended Links||Linux Run Levels||RHEL Runlevels||Creating your own init scripts|
|service||chkconfig||Xinetd||Booting into Rescue Mode||insserv||Grub|
|Boot Directly into a Shell||Suse init scripts||Admin Horror Stories||Etc|
There are two widespread urban myth about init scripts. The first is that scripts on lower runlevels are executed before scripts on higher runlevel. For example if we go to level 5 that means that scripts on level 3 will be executed. This is not true -- each runlevel is completely autonomous and sequence of runlevel is poorly logical. Only scripts belonging to particular runlevel are executed.
On entering particular run-level first all K-scripts are executed in sorted order. Then all S-scripts, the scripts that start daemons that should be present on a particular run-level are executed.
There are two types of scripts in /etc/init.d:
- Scripts Executed Directly by init
- This is the case only during the boot process or if an immediate system shutdown is initiated (power failure or a user pressing Ctrl-Alt-Del).
- Scripts that are sources by directly executed scripts
- functions and networking are most common scripts in this category.
All scripts are located in /etc/init.d. Scripts for changing the runlevel are also found there, but are called through symbolic links from one of the subdirectories (/etc/init.d/rc0.d to /etc/init.d/rc6.d). This is just for clarity reasons and avoids duplicate scripts if they are used in several runlevels. Because every script can be executed as both a start and a stop script, these scripts must understand the parameters start and stop. In addition most script understand the restart, reload, force-reload, and status options. These options are not necessary for correct functioning of the script:
Option Description start Start service. stop Stop service. restart If the service is running, stop it then restart it. If it is not running, start it. reload Reload the configuration without stopping and restarting the service. force-reload Reload the configuration if the service supports this. Otherwise, do the same as if restart had been given. status Show current status of service.
Links in each runlevel-specific subdirectory make it possible to associate scripts with different runlevels. When installing or uninstalling packages, such links are added and removed with the help of the program insserv (or using /usr/lib/lsb/install_initd, which is a script calling this program). See the manual page of insserv for details.
Below is a short introduction to the boot and stop scripts launched first or last, respectively, as well as an explanation of the maintaining script.
- Executed while starting the system directly using init. It is independent of the chosen runlevel and is only executed once. Here, the proc and pts file systems are mounted and blogd (boot logging daemon) is activated. If the system is booted for the first time after an update or an installation, the initial system configuration is started.
The blogd daemon is a service started by boot and by rc before any other one. It is stopped after the actions triggered by the above scripts (running a number of subscripts, for example) are completed. blogd writes any screen output to the log file /var/log/boot.msg, but only if and when /var is mounted read-write. Otherwise, blogd buffers all screen data until /var becomes available. Get further information about blogd with man blogd.
The script boot is also responsible for starting all the scripts in /etc/init.d/boot.d with a name that starts with S. There, the file systems are checked and loop devices are configured if needed. The system time is also set. If an error occurs while automatically checking and repairing the file system, the system administrator can intervene after first entering the root password. Last executed is the script boot.local.
- Here, enter additional commands to execute at boot before changing into a runlevel. It can be compared to AUTOEXEC.BAT on DOS systems.
- This script is executed when changing from single user mode to any other runlevel and is responsible for a number of basic settings, such the keyboard layout and initialization of the virtual consoles.
- This script is only executed while changing into runlevel 0 or 6. Here, it is executed either as halt or as reboot. Whether the system shuts down or reboots depends on how halt is called.
- This script calls the appropriate stop scripts of the current runlevel and the start scripts of the newly selected runlevel.
To start any custom program after all "standard" startup scripts one usually adds a corresponding line to /etc/rc.local You can also use cron
The first step is booting the kernel. As described in the previous section, this can be done from floppy or hard drive. As the kernel loads into memory, it will print messages to the system console, but usually also saves them in the system log files as well. As root, you can always check the file /var/log/messages (which contains kernel messages emitted during runtime as well). The command dmesg prints out the last lines of the kernel message ring buffer; directly after booting, naturally, you will get the boot messages, such as (not necessarily the same, and not necessarily in the same order):
These messages are all printed by the kernel itself, as each device driver is initialized. The exact messages printed depend on what drivers are compiled into your kernel and what hardware you have on your system. Here's a quick rundown on what they mean.
First, the kernel reports which console font it has picked and which console type it has detected
Next, the kernel gathers information about the PCI bus and checks for any PCI cards present in the system.
The next message printed is the "BogoMips" calculation for your processor. This is an utterly bogus (hence the name) measurement of processor speed, which is used to obtain optimal performance in delay loops for several device drivers. The kernel also prints information on the system memory:
Memory: 14984k/16384k available (552k kernel code, 384k reserved, 464k data)Here, we see that 14984k of RAM are available for the system to use. This means the kernel itself is using 1400k.
The networking code in the kernel is then initialized and the CPU type checked. You can see from the line:
Intel Pentium with F0 0F bug - workaround enabled.
that the Linux kernel is even clever enough to detect the infamous Pentium bug and provide a workaround. The line:
Linux version 2.0.35 (root@rabbit) (gcc version egcs-2.90.29 980515\ (egcs-1.0.3 release)) #3 Fri Nov 13 15:07:45 CET 1998
tells you the version number of the kernel and who has compiled it on which machine (in this case, it was root on the machine rabbit and which compiler was used). The serial device driver is then initialized, which prints information on each detected serial port. A line such as:
tty00 at 0x03f8 (irq = 4) is a 16550Ameans that the first serial device (/dev/tty00, or COM1) was detected at address 0x03f8, IRQ 4, using 16550A UART functions. Next comes configuration and checking for a SCSI host adapter. The kernel prints out information about all SCSI devices found. The line:
Adding Swap: 130748k swap-space (priority -1)
tells you how much swap space the kernel has found. Among the further tasks performed during a typical boot are finding and configuring a parallel port (lp1), detecting and configuring the network card, and finally setting up the ISDN subsystem. The last thing it reports is the detection of the floppy disk driver. Depending on your hardware, other messages will be printed in addition to those given in the example. For example, parallel port and SCSI drivers will be initialized at this point, if you have them.
Once the device drivers are initialized, the kernel executes the program init, which is found in /etc, /bin, or /sbin (it's /sbin/init on most systems). init is a general-purpose program that spawns new processes and restarts certain programs when they exit. For example, each virtual console has a getty process running on it, started by init. When you exit from a login session on one of the virtual consoles, the getty process exits, and init starts a new one, allowing you to log in again.
init is also responsible for running a number of programs and scripts when the system boots. Everything init does is controlled by the file /etc/inittab. Each line in this file is of the format:
code:runlevels:action:commandcode is a unique one- or two-character sequence used to identify this entry in the file. Several of the entries must have a particular code to work correctly; more on this later.
runlevels is the list of "runlevels" in which this entry should be executed. A runlevel is a number or letter that specifies the current system state, as far as init is concerned. For example, when the system runlevel is changed to 3, all entries in /etc/inittab containing 3 in the runlevels field will be executed. Runlevels are a useful way to group entries in /etc/inittab together. For example, you might want to say that runlevel 1 executes only the bare minimum of configuration scripts, runlevel 2 executes everything in runlevel 1 plus networking configuration, runlevel 3 executes everything in levels 1 and 2 plus dial-in login access, and so on. Today, the Red Hat distribution is set up so that runlevel 5 automatically starts the X Window System graphical interface. The SuSE distribution does it at runlevel 3, and the Debian distribution does so at runlevel 2--provided you have installed X.
For the most part, you don't need to concern yourself with runlevels. When the system boots, it enters the default runlevel (set in /etc/inittab, as we will soon show). On most systems, this default is runlevel 2 or 3. After we discuss normal booting, we'll show you how to enter another runlevel that you will sometimes need to use--runlevel 1, or single-user mode.
Let's take a look at a sample /etc/inittab file:
# Set the default runlevel to three id:3:initdefault: # Execute /etc/rc.d/rc.sysinit when the system boots si:S:sysinit:/etc/rc.d/rc.sysinit # Run /etc/rc.d/rc with the runlevel as an argument 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 # Executed when we press ctrl-alt-delete ca::ctrlaltdel:/sbin/shutdown -t3 -rf now # Start agetty for virtual consoles 1 through 6 c1:12345:respawn:/sbin/agetty 38400 tty1 c2:12345:respawn:/sbin/agetty 38400 tty2 c3:45:respawn:/sbin/agetty 38400 tty3 c4:45:respawn:/sbin/agetty 38400 tty4 c5:45:respawn:/sbin/agetty 38400 tty5 c6:45:respawn:/sbin/agetty 38400 tty6
Fields are separated by colons. The last field is the most recognizable: it is the command that init executes for this entry. The first field is an arbitrary identifier (it doesn't matter what it is so long as it's unique in the file) while the second indicates what runlevels cause the command to be invoked. The third field tells init how to handle this entry; for example, whether to execute the given command once or to respawn the command whenever it exits.
The exact contents of /etc/inittab depend on your system and the distribution of Linux you have installed.
In our sample file, we see first that the default runlevel is set to 3. The action field for this entry is initdefault, which causes the given runlevel to be set to the default. That's the runlevel normally used whenever the system boots. You can override the default with any level you want by running init manually (which you might do when debugging your configuration) and passing in the desired runlevel as an argument. For instance, the following command shuts down all current processes and starts runlevel 5 (warn all your users to log off before doing this!):
tigger# init 5
The next entry tells init to execute the script /etc/rc.d/rc.sysinit when the system boots. (The action field is sysinit, which specifies that this entry should be executed when init is first started at system boot.) This file is simply a shell script containing commands to handle basic system initialization; for example, swapping is enabled, filesystems are checked and mounted, and the system clock is synchronized with the CMOS clock.
Next, we see that the system executes the script /etc/rc.d/rc when it enters any of the runlevels 0 through 6, with the appropriate runlevel as an argument. rc is a generic startup script that executes other scripts as appropriate for that runlevel. The action field here is wait, which tells init to execute the given command, and to wait for it to complete execution before doing anything else.
Linux stores startup commands in files with rc in the name, using an old Unix convention. The commands do all the things necessary to have a fully functioning system. Thanks to these commands, the system comes up ready with logging facilities, mail, a web server, or whatever you installed and asked it to run. As explained in the previous section, the files are invoked from /etc/inittab. The commands are standard shell commands, and you can simply read the various rc files to see what they do.
In this section, we describe the structure of the rc files, so you understand where everything starts and can start or stop servers manually in the rare case that they don't do what you want them to do. We'll use Red Hat as our model, but once you get the idea of what to look for, you can find the corresponding files on any Linux distribution.
On Red Hat, the top-level rc script is /etc/rc.d/rc. The path is slightly different in other distributions (/etc/init.d/rc on Debian, for instance) but the contents are similar. In the previous section, you could see how the /etc/inittab invokes the script under a variety of circumstances with different numbers from 0 to 6 as arguments. The numbers correspond to runlevels, and each one causes the rc files to invoke a different set of scripts. So our next step is to find the scripts corresponding to each runlevel.
On Red Hat, scripts for each runlevel are stored in the directory /etc/rc.d/rcN.d where N is the runlevel being started. Thus, for runlevel 3, scripts in /etc/rc.d/rc3.d would be used. Again, slightly different conventions are the rule in other distributions. On Debian, for instance, the directory for each runlevel is /etc/rcN.d/.
Take a look in one of those directories; you will see a number of filenames of the form Snnxxxx or Knnxxxx where nn is a number from 00 to 99, and xxxx is the name of some system service. The scripts whose names begin with K are executed by /etc/rc.d/rc first to kill any existing services, then the scripts whose names begin with S are executed to start new services.
The numbers nn in the names are used to enforce an ordering on the scripts as they are executed: scripts with lower numbers are executed before those with higher numbers. The name xxxx is simply used to help you identify which system service the script corresponds to. This naming convention might seem odd, but it makes it easy to add or remove scripts from these directories and have them automatically executed at the appropriate time by /etc/rc.d/rc. For customizing startup scripts, you'll find it convenient to use a graphical runlevel editor, such as ksysv, in the KDE (see "Section 11.3, "The K Desktop Environment"" in Chapter 11, "Customizing Your X Environment").
For example, the script to initialize networking might be called S10network, while the script to stop the system logging daemon might be called K70syslog. If these files are placed in the appropriate /etc/rc.d/rcN.d directories, /etc/rc.d/rc will run them, in numerical order, at system startup or shutdown time. If the default runlevel of your system is 3, look in /etc/rc.d/rc3.d to see which scripts are executed when the system boots normally.
Because the same services are started or stopped at different runlevels, the Red Hat distribution uses symbolic links instead of repeating the same script in multiple places. Thus, each S or K file is a symbolic link that points to a central directory that stores startup or shutdown scripts for all services. On Red Hat, this central directory is /etc/rc.d/init.d, while on SuSE and Debian, it is /etc/init.d. On Debian, the directory contains a script called skeleton that you can adapt to start and stop any new daemons you might write.
Knowing the location of a startup or shutdown script is useful in case you don't want to completely reboot or enter a different runlevel, but need to start or stop a particular service. Look in the init.d directory for a script of the appropriate name and execute it, passing the parameter start or stop. For example, on SuSE, if you want the Apache web server to be running but your system is in a runlevel that does not include Apache, just enter the following:
# /sbin/init.d/apache start
Another important system configuration script is /etc/rc.d/rc.local, which is executed after the other system-initialization scripts are run. (How is this accomplished? Generally, a symbolic link to rc.local is made in each /etc/rc.d/rcN.d directory with the name S99local. Since 99 is the largest numerical order any of the S scripts can have, it is executed last. Voila!) You can edit rc.local to accomplish any peculiar or otherwise out-of-place system commands at boot time, or if you're not sure where else they should be executed. Debian doesn't have an equivalent of rc.local script, but nothing stops you from adding it and invoking it from rc if you're used to having it.
The next entry, labeled ca, is executed when the key combination Ctrl-Alt-Del is pressed on the console. This key combination produces an interrupt that usually reboots the system. Under Linux, this interrupt is caught and sent to init, which executes the entry with the action field of ctrlaltdel. The command shown here, /sbin/shutdown -t3 -rf now, will do a "safe" reboot of the system. This way we protect the system from sudden reboot when Ctrl-Alt-Del is pressed.
Finally, the inittab file includes entries that execute /sbin/agetty for the first six virtual consoles. agetty is one of the several getty variants available for Linux. These programs permit logins on terminals; without them the terminal would be effectively dead and would not respond when a user walked up and pressed a key or mouse button. The various getty commands open a terminal device (such as a virtual console, or a serial line), set various parameters for the terminal driver, and execute /bin/login to initiate a login session on that terminal. Therefore, to allow logins on a given virtual console, you must be running getty or agetty on it. agetty is the version used on a number of Linux systems, but others use getty, which has a slightly different syntax. See the manual pages for getty and agetty on your system.
agetty takes two arguments: a baud rate and a device name. The port names for Linux virtual consoles are /dev/tty1, /dev/tty2, and so forth. agetty assumes the given device name is relative to /dev. The baud rate for virtual consoles should generally be 38400.
Note that the action field for each agetty entry is respawn. This means that init should restart the command given in the entry when the agetty process dies, which is every time a user logs out.
Now you should be familiar with init, but the various files and commands in /etc/rc.d, which do all of the work, remain a mystery. We can't delve into these files without more background on other system administration tasks, such as managing filesystems. We'll lead you through these tasks in the next few chapters, and eventually all should be clear.
The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D
Copyright © 1996-2018 by Dr. Nikolai Bezroukov. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) in the author free time and without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|You can use PayPal to make a contribution, supporting development of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info|
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.
Last modified: March, 12, 2019