Creating your own linux custom init scripts

There are basically two standard types of linux system init.d scripts. They are the LSB and SysV init style init scripts.

Sysv init script writing method has traditionally been used to write init scripts in many linux distributions and is preferred as it gives more flexibility that earlier unix BSD style init script processes lacked. However, the more recent LSB (linux standard base) init.d script standard is widely used for its ability to reduce the challenges faced when migrating between different linux distributions and hence the difference between the scripting techniques is minimal.

Most Sysv init scripts are stored in the /etc/rc.d/init.d/ or /etc/init.d directory and are used to control how daemons start or stop up during system shutdown and startup.

SystemV-style initscripts and LSB header templates with detailed explained sections

# chkconfig:     
# description: <description, split="" multiple="" lines="" with="" \="" #="" a="" backslash="">

# Provides: 
# Required-Start: 
# Required-Stop: 
# Should-Start: 
# Should-Stop: 
# Default-Start: 
# Default-Stop: 
# Short-Description: 
# Description:      

LSB header example

# Provides: OurDB
# Required-Start: $local_fs $network $remote_fs
# Required-Stop: $local_fs $network $remote_fs
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: start and stop OurDB
# Description: OurDB is a very fast and reliable database
#              engine used for illustrating init scripts

When creating a script for the first time to startup your application, the run-level process as sequenced in the /etc/inittab file will probably warn you about the script failing to meet all requirements, which is less of a risk given the script will still work as long as the syntaxes are correctly written. A critical example is the # chkconfig syntax.

# chkconfig: 35 90 12
# description: Foo server
# Get function from functions library
. /etc/init.d/functions
# Start the service FOO
start() {
        initlog -c "echo -n Starting FOO server: "
        /path/to/FOO &
        ### Create the lock file ###
        touch /var/lock/subsys/FOO
        success $"FOO server startup"
# Restart the service FOO
stop() {
        initlog -c "echo -n Stopping FOO server: "
        killproc FOO
        ### Now, delete the lock file ###
        rm -f /var/lock/subsys/FOO
### main logic ###
case "$1" in
        status FOO
        echo $"Usage: $0 {start|stop|restart|reload|status}"
        exit 1
exit 0

        echo "Usage:  {start|stop|status|reload|restart[|probe]"
        exit 1
exit $?

a wrong # chkconfig syntax error will make it hard for chkconfig to call the script when it is time for the scripts to enter its specified run-level.

# chkconfig: 2345 20 80
# description: Saves and restores system entropy pool for \
#              higher quality random number generation.

It is always advisable not to manipulate the scripts manually but to let the to let chkconfig handle updating the /etc/init.d directory. A closer look at the chkonfig functions in a init.d script; the  first line tells chkconfig what run-levels the service should be started in by default, as well as the start and stop priority levels. If the service should not, by default, be started in any run-levels, a should be used in place of the run-levels list.

The second line contains a description for the service, and may be extended across multiple lines with backslash continuation. The /etc/innitab file makes it easier for the system during startup to understand the applications to run at certain run-levels and execute them .

A default innittab file template structure

# inittab   This file describes how the INIT process should set up
#           the system in a certain run-level.# Default run level. The run levels are:
#   0 - halt (Do NOT set initdefault to this)
#   1 - Single user mode
#   2 - Multiuser, without NFS 
#       (The same as 3, if you do not have networking)
#   3 - Full multiuser mode
#   4 - unused
#   5 - X11
#   6 - reboot (Do NOT set initdefault to this)

There are several tools available to relieve System administrators from directly updating the /etc/init.d directory which contains several other subdirectories directories that links it to the /etc/rc[x].d directory hierachy with numerous symbolic links contained in it.

In a Red-hat or cent OS systems the chkconfig tool or the ntsysv are mostly useful to accomplish the process of updating the /etc/init.d directory and you can therfore run the commands as root to enable the scripts automatically at boot.

chkconfig –add scriptname

chkconfig scriptname on

Running chkconfig --list scriptname should help you know whether the script will correctly be executed when entering/exiting the relevant runlevels.

on Debian-based distributions you can do this by running

update-rc.d scriptname defaults

A deep understanding of the shell functions provided by the init.d scripts is needed while filling them in the  init.d bash scripts as failure to do so may possibly deliver  unpredictable results while your system attempts to execute certain applications or daemons at run-levels.


Comments are closed.

%d bloggers like this: