Christopher Hallinan - Embedded Linux Primer - A Practical, Real-World Approach

Listing 6-4. Runlevel Directory Structure

$ ls -l /etc/rc.d

total 96

drwxr-xr-x 2 root root 4096 Oct 20 10:19 init.d

-rwxr-xr-x 1 root root 2352 Mar 16 2004 rc

drwxr-xr-x 2 root root 4096 Mar 22 2005 rc0.d

drwxr-xr-x 2 root root 4096 Mar 22 2005 rc1.d

drwxr-xr-x 2 root root 4096 Mar 22 2005 rc2.d

drwxr-xr-x 2 root root 4096 Mar 22 2005 rc3.d

drwxr-xr-x 2 root root 4096 Mar 22 2005 rc4.d

drwxr-xr-x 2 root root 4096 Mar 22 2005 rc5.d

drwxr-xr-x 2 root root 4096 Mar 22 2005 rc6.d

-rwxr-xr-x 1 root root 943 Dec 31 16:36 rc.local

-rwxr-xr-x 1 root root 25509 Jan 11 2005 rc.sysinit

Each of the runlevels is defined by the scripts contained in the rc N .d, where N is the runlevel. Inside each rc N .d directory, you will find numerous symlinks arranged in a specific order. These symbolic links start with either a K or an S. Those beginning with S point to service scripts, which are invoked with startup instructions; those starting with a K point to service scripts that are invoked with shutdown instructions. An example with a very small number of services might look like Listing 6-5.

Listing 6-5. Example Runlevel Directory

lrwxrwxrwx 1 root root 17 Nov 25 2004 S10network -> ../init.d/network

lrwxrwxrwx 1 root root 16 Nov 25 2004 S12syslog -> ../init.d/syslog

lrwxrwxrwx 1 root root 16 Nov 25 2004 S56xinetd -> ../init.d/xinetd

lrwxrwxrwx 1 root root 16 Nov 25 2004 K50xinetd -> ../init.d/xinetd

lrwxrwxrwx 1 root root 16 Nov 25 2004 K88syslog -> ../init.d/syslog

lrwxrwxrwx 1 root root 17 Nov 25 2004 K90network -> ../init.d/network

In this example, we are instructing the startup scripts to start three services upon entry to this fictitious runlevel: network, syslog, and xinetd. Because the S* scripts are ordered with a numeric tag, they will be started in this order. In a similar fashion, when exiting this runlevel, three services will be terminated: xinetd, syslog, and network. In a similar fashion, these services will be terminated in the order presented by the two-digit number following the K in the symlink filename. In an actual system, there would undoubtedly be many more entries. You can include your own entries for your own custom applications, too.

The top-level script that executes these service startup and shutdown scripts is defined in the init configuration file, which we now examine.

When init is started, it reads the system configuration file /etc/inittab. This file contains directives for each runlevel, as well as directives that apply to all run-levels. This file and init 's behavior are well documented in man pages on most Linux workstations, as well as by several books covering system administration. We do not attempt to duplicate those works; we focus on how a developer might configure inittab for an embedded system. For a detailed explanation of how inittab and init work together, view the man page on most Linux workstations by typing man initand man inittab.

Let's take a look at a typical inittab for a simple embedded system. Listing 6-6 contains a simple inittab example for a system that supports a single runlevel as well as shutdown and reboot.

Listing 6-6. Simple Example inittab

# /etc/inittab

# The default runlevel (2 in this example)

id:2:initdefault:

# This is the first process (actually a script) to be run.

si::sysinit:/etc/rc.sysinit

# Execute our shutdown script on entry to runlevel 0

l0:0:wait:/etc/init.d/sys.shutdown

# Execute our normal startup script on entering runlevel 2

l2:2:wait:/etc/init.d/runlvl2.startup

# This line executes a reboot script (runlevel 6)

l6:6:wait:/etc/init.d/sys.reboot

# This entry spawns a login shell on the console

# Respawn means it will be restarted each time it is killed

con:2:respawn:/bin/sh

This very simple [52] This inittab is a nice example of a small, purpose-built embedded system. inittab script describes three individual runlevels. Each run-level is associated with a script, which must be created by the developer for the desired actions in each runlevel. When this file is read by init, the first script to be executed is /etc/rc.sysinit. This is denoted by the sysinit tag. Then init enters runlevel 2, and executes the script defined for runlevel 2. From this example, this would be /etc/init.d/runlvl2.startup. As you might guess from the :wait: tag in Listing 6-6, init waits until the script completes before continuing. When the runlevel 2 script completes, init spawns a shell on the console (through the /bin/sh symbolic link), as shown in the last line of Listing 6-6. The respawn keyword instructs init to restart the shell each time it detects that it has exited. Listing 6-7 shows what it looks like during boot.

Listing 6-7. Example Startup Messages

...

VFS: Mounted root (nfs filesystem).

Freeing init memory: 304K

INIT: version 2.78 booting

This is rc.sysinit

INIT: Entering runlevel: 2

This is runlvl2.startup

#

The startup scripts in this example do nothing except announce themselves for illustrative purposes. Of course, in an actual system, these scripts enable features and services that do useful work! Given the simple configuration in this example, you would enable the services and applications for your particular widget in the /etc/init.d/runlvl2.startup script and do the reversedisable your applications, services, and devicesin your shutdown and/or reboot scripts. In the next section, we look at some typical system configurations and the required entries in the startup scripts to enable these configurations.

Although simple, this example startup script is designed to illustrate the mechanism and guide you in designing your own system startup and shutdown behavior. This example is based on busybox, which has a slightly different initialization behavior than init. These differences are covered in detail in Chapter 11.

In a typical embedded appliance that contains a web server, we might want several servers available for maintenance and remote access. In this example, we enable servers for HTTP and Telnet access (via inetd). Listing 6-8 contains a simple rc.sysinit script for our hypothetical web server appliance.

Listing 6-8. Web Server rc.sysinit

#!/bin/sh

echo "This is rc.sysinit"

busybox mount -t proc none /proc

# Load the system loggers

syslogd

klogd

# Enable legacy PTY support for telnetd

busybox mkdir /dev/pts

busybox mknod /dev/ptmx c 5 2

busybox mount -t devpts devpts /dev/pts

In this simple initialization script, we first enable the proc file system. The details of this useful subsystem are covered in Chapter 9. Next we enable the system loggers so that we can capture system information during operation. This is especially useful when things go wrong. The last entries enable support for the UNIX PTY subsystem, which is required for the implementation of the Telnet server used for this example.