Howto: Write A Suse Boot Script

This HowTo focuses on writing SUSE boot scripts and provides a simple example of a correctly written boot script.
Before you write a SUSE boot script, you have to make it "YaST Runlevel" aware. What this means is that before you actually write the code that will do something, you first write a few specific YaST lines so that when you go to YaST -> System -> System Services (Runlevel), the YaST module will recognize a few things in it, like in which runlevel the script has to be started, should something else be started before the script is executed and its desired runlevel shutdown.

A example of the YaST Runlevel lines is

### BEGIN INIT INFO
# Provides:****** network
# Required-Start: $local_fs dbus haldaemon
# Should-Start: isdn
# Required-Stop:
# Should-Stop:
# Default-Start:**2 3 5
# Default-Stop:**0 6
# Description:****Configure the network interfaces and set up routing
### END INIT INFO

The first thing you see is the ### BEGIN INIT INFO. This line, and all the lines below it, are read by YaST. The last line is ### END INIT INFO which tells YaST to finish reading the runlevel/service requirements of this script.

The # Provides: line describes the name of the script, in this case it is a boot script called "network" which is responsible for bringing the network up or down.

The second line # Required-Start: $local_fs dbus haldaemon tells the YaST runlevel module that these services (local_fs, dbus and haldaemon) should be started before the "network" script. This tells the runlevel editor to assign the correct boot order for this script

The third line, # Should-Start: isdn tells the runlevel editor that it may start the ISDN subsystem if it is presented, but it is not required to do so.

The fourth line, # Required-Stop: tells the runlevel editor that a specific service must be stopped before starting the "network" script. If you leave it empty as above, then the runlevel editor will skip it

The fifth line # Should-Stop: tells the runlevel editor that a service may be stopped before starting the "network" script, but it is not required

The sixth line # Default-Start: 2 3 5 tells the runlevel editor in which runlevel the "network" script should be started. In the above example, it will be started in runlevel 2, 3 and 5

The seventh line # Default-Stop: 0 6 tells the runlevel editor in which runlevel it should stop the "network" script. In the above example, it is in runlevel 0 and 6 (halt and reboot)

The eighth line # Description: is for a short description of the script so if you go to the YaST runlevel editor, you can see what the script does before enabling it

There are a few more "YaST lines" but the above ones are the most important ones. If you want the YaST runlevel editor to be aware of your boot script and its required services/runlevels, then you should use them. Of course, this is not necessary (meaning you can write a script without the YaST lines in it but then the Runlevel editor won't be able to check its requirements/runlevels)

The next thing you do, is include a so-called "status" script which gives color output to your script when booting up. The "status" script is located in /etc and is called rc.status. This means that when you boot up, if the boot script you just wrote is set to active, then the "status" script will provide colored status information after the specific commands are executed. If your boot script fails to come up or something went wrong, you'll see a red colored "failed" line as output. If your boot script comes up without a problem, then you'll see a green colored output saying "done"

Again, this is not really required but it is recommended to get used to this. Other Linux distros provide similar colored output statuses for boot scripts so it is not SUSE specific.

You can include this "status" script into your boot script by adding this right after the YaST lines

. /etc/rc.status

Note the space between the . (point) and the first / (forward slash)

After that, you have to reset its status with

rc_reset

Now comes the actual code you write in your boot script to do something. Before writing the code, you have to understand how boot scripts are started and stopped.

When the system brings up a boot script, it calls it by its name with a specific parameter. For example, the "network" boot script, when executing it at boot time, will be called by the system like this: network start
When bringing the script down, it will be called by the system like this: network stop

The start and stop parameters are understood by the system and must be presented in all boot scripts with the exception of /etc/init.d/boot.local. Other parameters are: status (to check the status of the script) and restart (to restart the script). There are others which are more specific to the services you use in your boot script. For example, the "network" boot scripts uses in addition to the above parameters also these: reload, force-reload, try-restart, stop-all-dhcp-clients, restart-all-dhcp-clients

If the boot script is coded in a proper way, then if you execute it without any parameters, it'll show you which parameters it supports and exit with a none-zero exit status.

Now, lets have a look at a simple boot script example. Say you want to create a public bittorrent tracker and you want to write a boot script for it so that every time you boot up your computer, it will be started automatically. I take a bittorrent tracker as an example because I actually have one running and I wrote the boot script for it. If you want to use the script below, then you have to install the "BitTorrent" package which contains "bttrack"

#!/bin/sh

### BEGIN INIT INFO
# Provides:************bt-tracker
# Required-Start:******$network
# Required-Stop:
# Default-Start:****** 2 3 5
# Default-Stop:********0 1 6
# Description:******** Start the bittorrent tracker
### END INIT INFO

# Set global variables

LOGDIR=/var/log/bt-tracker
DS=/var/run/bt-tracker
BTTRACK=/usr/bin/bttrack
PORT=6969

# Check to see if executable "bttrack"
# is presented. If not then exit with a
# none-zero status

test -x $BTTRACK || exit 5

# Check to see if log directories
# are there. If not then make them

test -d $LOGDIR || mkdir -p $LOGDIR
test -d $DS || mkdir -p $DS

# Include the status script and
# clear its status

. /etc/rc.status
rc_reset

case "$1" in
****start)
****echo -n "Starting bittorrent tracker"
****startproc $BTTRACK --port $PORT --dfile $DS/dstate --logfile $LOGDIR/tracker.log
****rc_status -v
;;
****stop)
****echo -n "Stopping bittorrent tracker"
****killproc -TERM $BTTRACK
****rc_status -v
;;
****restart)
****$0 stop
****$0 start
****rc_status
;;
****status)
****echo -n "Checking status of bttrack: "
****checkproc $BTTRACK
****rc_status -v
;;
*****)
****echo "Usage: $0 {start|stop|restart|status}"
****exit 1
;;
esac

As you can see above, the script is pretty self-explaining. First, you have the YaST lines at the top which define some script specific settings like the name of the script, runlevels and required services which should be started before this script. As we deal here with a bittorrent tracker, then the network must be already running before this script, hence you put $network in # Required-Start:

Then, you set some global variables, like the location of the program/daemon, log files, etc. After that, you do a few checks to see if all is presented. If not, then just exit from the boot script. Just before the case "$1" conditional, you include the "status" script from /etc and reset its value using the rc_reset command

As you can see, the real stuff is placed after the case conditional. After the start) parameter of the case conditional, you write the commands to do something, like bringing a specific service up. After the stop) parameter of the case conditional you write the commands to stop something. The restart) parameter does exactly as its name says, it first stops the service, then it starts it up again. The final *) parameter is used by the script to display its usage if the script is ran without any parameters from the command line. So, if you open up a console and do a service bt-tracker (bt-tracker is the name I used for my boot script) without any parameters after bt-tracker, then you'll get this:

Usage: /etc/init.d/bt-tracker {start|stop|restart|status}

After every command, you put the rc_status -v command which comes from the "status" script. It will display a colored output of the status of your script. For example, if you issue this command as root:

service bt-tracker status

It will display the status of the script. If the script is running, it will say: Checking status of bttrack: running

If the script is not started yet, then the display message will be: Checking status of bttrack: unused

If the script fails to start for some reason, then the output will be: Checking status of bttrack: failed

There is one more status which is skipped. It means that the service in question starts without a problem but it is skipped by the system because it either isn't configured properly or is not compatible with your machine. A good example of such a service is the microcode boot script which updates the microcode of a Intel processor. If you try to run it on a AMD system, then this service will be skipped due to incompatible processor used by your computer

To start this boot script, you can use 2 methods, either with the "service" command or you can provide the script's full path together with a desired parameter (make sure the script is executable first - as root in a console, type chmod +x /path/to/script/name_of_boot_script), eg

service bt-tracker start

or

/etc/init.d/bt-tracker start

If you want to add this script to the boot process, then again you have 2 choices. Either use YaST -> System -> System Services (Runlevel) and activate it from there, or use the command below as root

chkconfig -a bt-tracker

There are some other more advanced functionality available for boot scripts but this is out of the scope of this HowTo as I only try to provide a simple and easy way to write a boot script in no time. If you want to understand the whole process of writing boot scripts for SUSE Linux systems, then read these files: /etc/init.d/skeleton and /etc/init.d/README.
The "skeleton" script is a example boot script you can use as reference to write your own, the README file provides information on booting and used runlevels in SUSE

Also make sure to take a look at the man page of "init" - the mother of all processes in Linux

Hope, that helps a bit

Hey there!

Is there a way to start a script that does not return anything, just hangs on command line, with respect to this guide?

Cheers

One more question...how can i add service control to my GRUB settings? Is it possible? Cheers