The BusyBox init system is a lightweight, minimalist alternative to traditional Linux init systems such as SysVinit or systemd. Designed primarily for embedded systems, BusyBox provides a comprehensive set of utilities in a single executable, making it ideal for resource-constrained environments like those found in Buildroot and Yocto projects. One of its key components is its init system, which is responsible for starting and stopping system services at boot and shutdown.
In this article, we’ll explore the BusyBox init system, how it fits into embedded Linux distributions like Buildroot and Yocto, and how to manage startup and shutdown scripts for custom services.
Understanding the BusyBox Init System
The init program in BusyBox serves as the first process that runs when a Linux system boots. It is responsible for initializing the system, launching the necessary system services, and ensuring proper shutdown on system halt or reboot. BusyBox’s init system is simpler than other init systems, which makes it suitable for embedded systems that prioritize efficiency and small footprints.
The BusyBox init system simplifies this process by providing a lightweight, single binary that can handle the initialization of the system, including:
- Running user-defined scripts at startup and shutdown.
- Setting up environment variables.
- Starting background processes or services.
- Handling shutdown sequences.
Why Use BusyBox Init?
BusyBox init is particularly popular for:
- Embedded Linux systems: Many embedded devices like routers, IoT devices, and small appliances rely on BusyBox for their compact footprint and efficiency.
- Minimalistic distributions: Linux distributions that focus on providing only the bare essentials often use BusyBox as their init system to keep system resources to a minimum.
- Customization: BusyBox init allows for a high degree of customization, enabling users to write their own scripts and configure services exactly as needed.
BusyBox Init Directory Structure
When BusyBox is configured as the init system, it typically expects a few essential directories and files:
- /etc/init.d/: Contains startup and shutdown scripts.
- /etc/inittab: Configuration file that defines the runlevels, which services to start, and which scripts to execute at various stages of boot or shutdown.
- /etc/rc.d/: Sometimes used for additional runlevel scripts, depending on the distribution.
/etc/inittab Configuration File
The /etc/inittab file is the heart of the BusyBox init system. It defines the system’s runlevels and what actions to take at each level. A typical /etc/inittab file looks like this:
# /etc/inittab
# Format for each entry: <id>:<runlevels-:<action>:process
# id == tty to run on , oor empty for /dev/console.
# runlevel == ignored (busbox does not support runlevels.
# action == one of sysinit , repawn , askfirst , wait and once
::sysinit:/etc/init.d/rcS # Initialize system
::shutdown:/etc/init.d/rc0 # Run shutdown scripts
::respawn:/sbin/getty 38400 tty1 # Spawn a login prompt on tty1
::ctrlaltdel:/sbin/reboot # Reboot on Ctrl+Alt+Del
ttyS0:respawn:/sbin/getty/ -L ttyS0 0 vt100 # Generic serial Here’s a breakdown of what each line represents:
- ::sysinit: Specifies the script to run for system initialization (often /etc/init.d/rcS).
- ::shutdown: Specifies the script to run during shutdown (/etc/init.d/rc0).
- ::respawn: A command to run on specified terminals, like spawning a login prompt (getty).
- ::ctrlaltdel: Configures the system to reboot when Ctrl+Alt+Del is pressed.
Writing Startup and Shutdown Scripts
Startup scripts are typically placed in the /etc/init.d/ directory. These scripts are executed in the order specified by the /etc/inittab file or . A simple script to start a service at boot might look like this:
# /etc/init.d/my_service
#!/bin/sh
case "$1" in
start)
echo "Starting My Service..."
/usr/bin/my_service &
;;
stop)
echo "Stopping My Service..."
killall my_service
;;
restart)
echo "Restarting My Service..."
/usr/bin/my_service &
;;
status)
pgrep -fl myservice
;;
*)
echo "Usage: $0 {start|stop|restart}"
exit 1
esac
exit 0Explanation:
- The script uses a case statement to handle different commands (start, stop, restart, status).
- When the script is executed with start, it launches the myservice binary in the background.
- The stop command kills any running myservice processes.
- The restart command first stops the service and then restarts it.
- The status command checks if myservice is running by using the pgrep command.
Making the Script Executable
After writing your script, make it executable with the following command:
chmod +x /etc/init.d/S05myAppManaging Startup and Shutdown Scripts
Scripts are executed based on the numerical order specified in their filenames:
- Scripts in the init.d directorie are executed in ascending numerical order (e.g., S01 to S99).
By modifying the numbers appended to the script filenames, you can control the precise sequence in which services are started during initialization or stopped during shutdown.
rcS and rcK files
rcS script: is located in the /etc/init.d/ directory and is typically executed by the BusyBox init process when the system boots into runlevel 3 (multi-user mode). It is an important part of the init system, and its primary function is to handle the initial system setup tasks before other services and applications are started.The rcS script is defined in the /etc/init.d/rcS file and is specified in /etc/inittab under the ::sysinit entry (which indicates it should be executed at system startup).After rcS is executed, the S scripts are executed.
rcK script: is the counterpart to rcS, and it is executed when the system shuts down or transitions to runlevel 0 (halt) or runlevel 6 (reboot).Its main role is to stop services, clean up resources, and ensure the system shuts down gracefully before powering off or rebooting.
Conclusion
The BusyBox init system provides a lightweight and flexible way to initialize and manage services on minimalistic Linux systems. By writing simple startup and shutdown scripts and properly configuring /etc/inittab and /etc/rc.d/ directories, you can easily customize how and when services are started or stopped.
This system is especially useful for embedded and resource-constrained environments, where efficiency is key, and full-fledged init systems like Systemd or SysVinit are not necessary. With BusyBox init, users have the flexibility to create a boot process tailored to their specific needs while keeping resource usage minimal.
