Article 3 of 15
Core Concept: Init Scripts
One of the Building Blocks of SysVinit
A runlevel describes the overall operating state of a SysVinit system.
But how does SysVinit actually bring that operating state about?
One of the important pieces is the init script.
On BcalcOS, these scripts can be found in:
/etc/init.d/
If you look inside that directory, you’ll find scripts with names such as:
cron
cups
networking
rsyslog
slim
ufw
These scripts contain instructions for managing the programs associated with them.
What Is an Init Script?
An init script is generally a shell script that provides instructions for starting, stopping, restarting, and sometimes checking the status of a service.
A typical init script can respond to commands such as:
start
stop
restart
status
For example:
sudo /etc/init.d/cron start
tells the cron init script to start the cron service.
Similarly:
sudo /etc/init.d/cron stop
tells it to stop the service.
The script provides the instructions for carrying out those operations.
What Does an Init Script Look Like?
Because init scripts are generally shell scripts, they can be opened and read using ordinary tools.
For example:
less /etc/init.d/cron
At the top of a typical script, you’ll find information describing what it provides and what it needs from other parts of the system.
The script then contains the commands and logic needed to handle operations such as starting and stopping the program.
You don’t have to be a super-user to get useful information from an init script.
Even a quick look can often tell you:
- what program the script manages
- where that program is located
- what configuration files it uses
- what commands are available
- what the script expects to be running first
That inspectability is one of the useful characteristics of the SysVinit approach.
A Real BcalcOS Example: Cron
BcalcOS includes the following init script:
/etc/init.d/cron
Inside that script we can find:
DAEMON=/usr/sbin/cron
This tells us that the script manages the cron program located at /usr/sbin/cron.
Scripts typically provide the usual operations for starting, stopping, restarting, and checking the program.
Conceptually, we can think of it this way:
/etc/init.d/cron
↓
instructions for managing
↓
/usr/sbin/cron
The init script is the set of instructions. The program being managed is a separate thing.
Another BcalcOS Example: SLiM
BcalcOS also has an init script for SLiM, the display manager used to provide the graphical login:
/etc/init.d/slim
The script identifies the program it manages:
DAEMON=/usr/bin/slim
Like the cron script, it provides commands for starting, stopping, restarting, and checking the program.
The SLiM example also shows that init scripts can contain additional logic.
For example, the script checks whether SLiM is configured as the system’s default display manager before attempting to start it. If it isn’t, the script does not start SLiM.
So an init script isn’t necessarily just a few commands saying “start this program.” It can contain the logic needed to manage that program appropriately.
Init Scripts Are Not SysVinit Itself
SysVinit is the init system.
Init scripts are tools that SysVinit uses as part of that process.
On BcalcOS, the init process is PID 1 and is responsible for bringing the system into its operating state.
So:
SysVinit
↓
determines the system's operating state
↓
uses the appropriate configuration
↓
runs init scripts
↓
init scripts manage programs
This is a simplified picture but it illustrates the basic relationship.
The init scripts are one of the mechanisms used to manage the system’s programs.
Why Use Scripts?
One of the appealing characteristics of traditional SysVinit is that much of the system’s service-management logic is visible in ordinary files.
A reasonably knowledgeable user can open an init script and read what it does.
Of course, not every init script is simple. Some are quite large and contain complicated logic.
But the underlying mechanism is familiar:
They are scripts that contain instructions.
This fits well with the traditional Unix philosophy of using relatively simple components that can be inspected and combined.
There are tradeoffs, though. Shell scripts aren’t necessarily the fastest or most sophisticated way to manage every situation.
But simplicity and inspectability have value too.
Key Takeaway
A runlevel describes the operating state the system wants to achieve.
An init script provides instructions for managing a particular program or service.
For example:
runlevel 2
↓
configuration for that operating state
↓
init script
↓
program being managed