BusyBox has a minimal init program that uses a configuration file, /etc/inittab, to define rules to start programs at boot up and to stop them at shutdown. Usually, the actual work is done by shell scripts which, by convention, are placed in the /etc/init.d directory.
init begins by reading the configuration file, /etc/inittab. This contains a list of programs to run, one per line, with this format:
<id>::<action>:<program>
The role of these parameters is as follows:
id: The controlling terminal for the commandaction: The conditions to run this command, as shown in the following paragraphprogram: The program to run
The actions are as follows:
sysinit: Run the program wheninitstarts, before any of the other types of actions.respawn: Run the program and restart it if it terminates. It is used to run a program as a daemon.askfirst: This is the same asrespawn, but prints the message Please press Enter to activate this console to the console and runs the program after Enter has been pressed. It is used to start an interactive shell on a terminal without prompting for a user name or password.once: Run the program once but do not attempt to restart it if it terminates.wait: Run the program and wait for it to complete.restart: Run the program wheninitreceives the signalSIGHUP, indicating that it should reload theinittabfile.ctrlaltdel: Run the program wheninitreceives the signalSIGINT, usually as a result of pressing Ctrl + Alt + Del on the console.shutdown: Run the program wheninitshuts down.
Here is a small example that mounts proc and sysfs and runs a shell on a serial interface:
null::sysinit:/bin/mount -t proc proc /proc null::sysinit:/bin/mount -t sysfs sysfs /sys console::askfirst:-/bin/sh
For simple projects in which you want to launch a small number of daemons and perhaps start a login shell on a serial terminal, it is easy to write the scripts manually, and this is appropriate if you are creating a RYO (roll your own) embedded Linux. However, you will find that hand-written init scripts rapidly become unmaintainable as the number of things to be configured increases. They tend not to be very modular and so need updating each time a new component is added.
Buildroot has been making effective use of BusyBox init for many years. Buildroot has two scripts in /etc/init.d named rcS and rcK. The first one starts at boot-up and iterates over all the scripts beginning with a capital S followed by two digits, and runs them in numerical order. These are the start scripts. The rcK script is run at shutdown and iterates over all the scripts beginning with a capital K followed by two digits, and runs them in numerical order. These are the kill scripts.
With this in place, it becomes easy for Buildroot packages to supply their own start and kill scripts, using the two digit number to impose the order in which they should be run, and so the system becomes extensible. If you are using Buildroot,this is transparent. If not, you could use it as a model for writing your own BusyBox init scripts.