The Problem

When you run a server then the server process has to be started. If you are installing a webserver like apache2 or lighttpd via the package manager then an autostart script will be installed as well. This is not the case if you want to run your self-compiled server like the dump1090 ADS-B receiver. In this case you have to provide the start (and also probably a stop-) script by yourself.

The Solution

The solution is simple. In the first step you have to provide a small script which starts and stops your server. In the second step you have to register it against the operating system. The exact procedure is described below.

A little theory: Linux Runlevels

A runlevel defines the state of the machine after boot. Different runlevels are typically assigned (not necessarily in any particular order) to the single-user mode, multiuser mode without network services started, multiuser mode with network services started, system shutdown, and system reboot system states. The exact setup of these configurations varies between operating systems and Linux distributions. For example, runlevel 4 might be a multi-user GUI no-server configuration on one distribution, and nothing on another. Runlevels commonly follow the general patterns described in this article; however, some distributions employ certain specific configurations.

Raspiban (the standard operating system of a RPi) is related to debian, and in debian runlevels are working as follows:

Where Does a Run Level Live?

Like everything else in a Linux system, run levels are defined by files in the filesystem. All the run level files are found in the directory according to the following table:

Notice a pattern? Each defined runlevel should have an rcX.d directory where X is the run level number. The contents of the rcX.d directory determines what happens at that run level.

(S)tart files, (K)ill files

Let's look at run level 2 since this is where we'll spend most of our time. Here are the contents of a generic rc2.d directory:

At first glance the files in this directory look kind of intimidating. They should be. The files in the rcX.d directories are formatted for the computer to read, not the user. Each file is a symbolic link to a script residing in the /etc/init.d directory and controls the starting, or stopping of a program, or daemon (service).

Working backwards, here is how the name parses out. The [string] is a human readable mnemonic for the executable file that is actually symbolically linked to. The 'nn' is a two digit number from 01-99; lower number programs are executed first. By this method, services that have a dependancy can be certain their precursor has ran. The K and S signify simply Kill, or Start.

When a system moves into a new runlevel, all the files that begin with S will be executed. When a system moves into a new runlevel all the files that begin with K will be executed. Yes, all the files will execute, but with one distinct difference: 'S' files invoke their program with the 'start' parameter, the 'K' files invoke their program with the 'stop' parameter. The UserLinux (Debian) system optimizes the runlevel change by not starting a daemon that is already running.

The simple elegance of this system is made possible by the alphabet. All the scripts will execute in alphabetical order. 'K' comes before 'S', so programs are stopped before they are started. Forgetting this fact can lead to a lot of chin scratching while manipulating your rcX.d files.

After the first letter comes the integer, again determining execution order. Finally, the mnemonic portion is followed alphabetically to determine execution order. All of these files have the same precedence as far as the system is concerned. They will be executed in the order listed, i.e. alphabetically. All of the scripts that run during system start-up actually reside in the /etc/init.d/ directory, as suggested by the listing. The reasons for this are many, but basically boil down to common sense issues like: saving space, single point for editing, and everyone knowing where to find things.

The final solution

Finally here is a sample how the content of such start / killscript (in my case the /etc/init.d/dump1090 looks like:

The upper script will be placed in the directory /etc/init.d and after it is marked as executable (e.g. via sudo chmod +x /etc/init.d/dump1090) then the service can be started and stopped with the commands. The attendive reader will recognise that program is not started directly, but with the start-stop-daemon program. The reason behind this is that the start-stop-daemon controls the creation and termination of system-level processes. Using the --exec, --pidfile, --user, and --name options, start-stop-daemon can be configured to find existing instances of a running process. This prevents that the same program will be started twice.

The final step is to tie the script to the correct runlevels. In the simplest case this command will work:

And finally: Here is another interesting article about the start process under ubuntu.