Customizing the boot process
 

Writing rc scripts There is no magic in writing rc-scripts. They are basically very small scripts that must fulfill certain criterias. If you have a little experience in writing shell scripts, you will be fine.
 
In Chapter 6, you saw that the job of an rc-script is to start and stop a particular service. You can of course have two scripts: one to start the service and one to stop it.
 

#! /bin/sh 
# Copyright (c) 1995-1998 SuSE GmbH Nuernberg, Germany. 
# 
# Author:  
# 
# /sbin/init.d/<skeleton> 
# 
#   and symbolic its link 
# 
# /sbin/rc<skeleton> 
# 

. /etc/rc.config 

# Determine the base and follow a runlevel link name. 
base=${0##*/} 
link=${base#*[SK][0-9][0-9]} 

 

# Force execution if not called by a runlevel directory. 
test $link = $base && START_FOO=yes 
test "$START_FOO" = yes || exit 0 

# The echo return value for success (defined in /etc/rc.config). 
return=$rc_done5 case "$1" in 

    start) 
        echo -n "Starting service foo" 
        ## Start daemon with startproc(8). If this fails 
        ## the echo return value is set appropriate. 

 

        #startproc /usr/sbin/foo || return=$rc_failed 

 

        echo -e "$return" 
        ;; 

    stop) 
        echo -n "Shutting down service foo" 
        ## Stop daemon with killproc(8) and if this fails 
        ## set echo the echo return value. 
        #killproc -TERM /usr/sbin/foo || return=$rc_failed 

 

        echo -e "$return" 
        ;; 

    restart) 
        ## If first returns OK call the second, if first or 
        ## second command fails, set echo return value. 
        $0 stop  &&  $0 start  ||  return=$rc_failed 
        ;; 

    reload) 
        ## Choose ONE of the following two cases: 

 

        ## First possibility: A few services accept a signal 
        ## to reread the (revised) configuration. 

 

        #echo -n "Reload service foo" 
        #killproc -HUP /usr/sbin/foo || return=$rc_failed 
        #echo -e "$return" 

 

        ## Exclusive possibility: Some services must be stopped 
        ## and started to force a new load of the configuration. 

 

        #$0 stop  &&  $0 start  ||  return=$rc_failed 
        ;; 

    status) 
        echo -n "Checking for service foo: " 
        ## Check status with checkproc(8), if process is running 
        ## checkproc will return with exit status 0. 

 

        #checkproc /usr/sbin/foo && echo OK || echo No process 
        ;; 

    probe) 
        ## Optional: Probe for the necessity of a reload, 
        ## give out the argument which is required for a reload. 

 

        #test /etc/foo.conf -nt /var/run/foo.pid && echo reload 
        ;; 

    *) 
        echo "Usage: $0 {start|stop|status|restart|reload|probe}" 
        exit 1 
        ;; 
esac 

# Inform the caller not only verbosely and set an exit status. 
test "$return" = "$rc_done" || exit 1 
exit 0 

After your script is ready, you should test it by calling with every possible parameter. It may be too late to fix errors when it's called during the boot process.
 
To add the script to a runlevel, it simply has to be linked into the runlevels subdirectory. The naming scheme was mentioned earlier. You need one link starting with a capital S to start the service when entering the runlevel, and one beginning with capital K to stop it when leaving. The two-digit number provides the order in which the scripts are executed. Scripts with lower numbers are started first. This is true for start and stop scripts. If, for example, your service needs networking, make sure that the number for the start link is higher than the one for the network script, and that the number for the stop link is lower. This ensures that networking is started prior to your service, and that your service will be stopped before the network goes down.
 
You can put links in each runlevel subdirectory you want your service to activate. A service is not limited to one runlevel.
 

We've seen how we can change the default runlevel, and how to customize a given runlevel by adding new services to it. The remaining task is to create a whole new runlevel.
 
Before you begin, carefully consider why you need to do it. It's not always easy to decide. For example, if you run a database server, you may assume that it would be handy to use runlevel 4 as the database server mode. That's not a bad idea, but do you really need a separate runlevel for the database?
 
To decide, think about the difference between the current runlevels and the one you have in mind. If the difference is that the database is the only addition, then it's not worth having a separate runlevel. You can start and stop the database by calling its rc-script as easily as changing between runlevels. But if you want to have only the database running and none of the other network services such as FTP, HTTP, DNS and SMTP server, then a separate runlevel might make sense. The greater the distance between the standard runlevels and your new runlevel, the more sense it makes to create a new one. Maybe this isn't the case at all. Maybe you want to create a new runlevel just to see how it works. Things don't always have to make sense or have a purpose. Sometimes it's simply nice to see what is in the realm of possibility.
 

# cd /sbin/init.d259  
# cp -d rc2.d/* rc4.d 

# cd /sbin/init.d/rc4.d 
# for i in axnet mysql apache apmd inn lpd rwhod sendmail sshd \\ 
nfsserver pcnfsd named routed nfs firewall masquerade serial ; do 
> rm ???$i 
> done 

l4:4:wait:/sbin/init.d/rc 4272 

1:1234:respawn:/sbin/mingetty --noclear tty1 
2:1234:respawn:/sbin/mingetty tty2 
3:1234:respawn:/sbin/mingetty tty3 
4:1234:respawn:/sbin/mingetty tty4 
5:1234:respawn:/sbin/mingetty tty5 
6:1234:respawn:/sbin/mingetty tty6 

# cd /sbin/init.d/rc4.d 
# ln -s ../myrcscript S20myrcsript 
# ln -s ../myrcscript K20myrcsript 
# ln -s ../mysecondrcscript S21mysecondrcsript 
# ln -s ../mysecondrcscript K19mysecondrcsript 

# init 4