SysVinit, or System V init, is the traditional initialization system that Linux distributions used to adopt to bootstrap the user space and manage system processes after the Linux kernel has been booted. Named after the Unix System V style of initialization, it represents one of the earlier approaches to system startup and service management in Unix-like operating systems. Here’s a closer look at how it works and its components:

1. The Init Process

• At boot time, the Linux kernel launches the init program, which is the first process (process 1) and the parent of all other processes. SysVinit provides this init program.

  

Image source: linuxtldr.com

2. Initialization and Runlevels

• /etc/inittab: This configuration file defines how the system should be initialized. SysVinit reads this file to determine the script to execute during the boot process.

• Runlevels: SysVinit introduces the concept of runlevels, which are modes of operation that dictate which services or processes are active. Common runlevels include:

  • 0: Halt

  • 1 or S: Single-user mode, mainly for maintenance

  • 2: Multi-user mode without networking (not used in all distributions)

  • 3: Full multi-user mode with networking but without a graphical interface

  • 5: Multi-user mode with networking and a graphical interface

  • 6: Reboot

3. Service Management

• Scripts: Services and daemons are managed through scripts located in /etc/init.d/ (or sometimes /etc/rc.d/), which can be started, stopped, or otherwise managed by passing them appropriate arguments.

• Runlevel Directories: These scripts are linked to specific runlevel directories (/etc/rcX.d/, where X is the runlevel number), which contain symbolic links to scripts in /etc/init.d/. The names of these links begin with S to start a service or K to kill a service, followed by a number indicating the order in which they should be processed.

4. Transition and Legacy

• Superseded by Systemd: Many Linux distributions have transitioned to systemd, a newer init system, due to its more robust features, faster boot times, and improved system management capabilities. However, SysVinit is still in use in certain distributions, especially those favoring traditional Unix philosophies or minimalism.

• Compatibility Layer: Systemd provides a compatibility layer for SysVinit scripts, allowing systems to continue using old init scripts under the new system.

SysVinit’s simplicity and straightforwardness made it a foundation for many Linux systems over the years. Despite being largely superseded by systemd in recent distributions, understanding SysVinit is crucial for managing older systems or distributions that still rely on this classic initialization system.

Workshop: Get acquainted with SysVinit

Exercise 1: Understanding the Init Process

Verify init as PID 1 and understand its role.

Steps:

1. Open the terminal.

2. Execute ps -p 1.

Solution:

• You should see output indicating that PID 1 is /sbin/init or just init, affirming it as the first process started by the Linux kernel.

  

Exercise 2: Exploring /etc/inittab

Familiarize yourself with the /etc/inittab file, which controls the init process.

Steps:

1. View /etc/inittab by executing cat /etc/inittab.

Solution:

• You will see various configurations, including system initialization, runlevel settings, and scripts executed at different runlevels. This file is crucial for customizing system boot behavior.

  

Exercise 3: Identifying and Changing Runlevels

Learn how to identify the current runlevel and change to a different runlevel.

Steps:

1. Identify the current runlevel by executing runlevel. For devuan based VM you have to type /sbin/runlevel

   

2. Change to multi-user mode without GUI (usually runlevel 3) by executing sudo telinit 3.

Solution:

• The initial runlevel command will show the current runlevel. After changing to runlevel 3, running runlevel again will confirm the change.

  

Exercise 4: Managing Services

Practice starting, stopping, and restarting services.

Steps:

1. Go to /etc/init.d/.

2. Choose a service, for example, ssh.

3. Start the service with sudo /etc/init.d/ssh start.

4. Stop the service with sudo /etc/init.d/ssh stop.

5. Restart the service with sudo /etc/init.d/ssh restart.

Exercise 5: Modifying Runlevel Services

Learn how to add or remove services from runlevels.

Steps:

1. Create a simple script in /etc/init.d/testservice (this can be a simple bash script that echoes a message).

    ### BEGIN INIT INFO
    # Provides:          testservice
    # Required-Start:    $local_fs $network
    # Required-Stop:     $local_fs
    # Default-Start:     2 3 4 5
    # Default-Stop:      0 1 6
    # Short-Description: Example service
    # Description:       This is an example service script.
    ### END INIT INFO
   
    echo "Test Service"
   

2. Make it executable with chmod +x /etc/init.d/testservice.

3. Add the service to default runlevels with sudo update-rc.d testservice defaults.

4. Verify by checking the relevant /etc/rcX.d/ directories.

   

5. Remove the service with sudo update-rc.d -f testservice remove.

Exercise 6: Hands-on Challenge

You are tasked with ensuring a custom script runs at startup, performing necessary system health checks.

Steps:

1. Write a simple bash script in /etc/init.d/customhealthcheck that logs system health information.

2. Make the script executable.

3. Add the script to run at runlevel 3.

4. Reboot the system and verify the script ran by checking its log output.

Hand-on Challenge Solution

For the hands-on challenge in Exercise 6, where you're tasked with ensuring a custom script runs at startup to perform system health checks, follow these steps to create and configure the script:

Step 1: Writing the Custom Script

1. Create the Script: Open a text editor (like nano or vi) to create your script in the /etc/init.d/ directory. Name it something descriptive, such as customhealthcheck.

    sudo nano /etc/init.d/customhealthcheck
   

2. Add the Script Contents: Below is a simple template for the script. It includes the necessary LSB tags and a simple command that appends a health check message to a file in /var/log/.

    #!/bin/bash
    ### BEGIN INIT INFO
    # Provides:          customhealthcheck
    # Required-Start:    $local_fs $network
    # Required-Stop:     $local_fs
    # Default-Start:     2 3 4 5
    # Default-Stop:      0 1 6
    # Short-Description: Perform system health check
    # Description:       Logs system health check status
    ### END INIT INFO
   
    case "$1" in
      start)
        echo "Performing system health check..."
        # Example health check: log disk usage
        echo "Disk usage as of $(date):" >> /var/log/healthcheck.log
        df -h >> /var/log/healthcheck.log
        ;;
      stop)
        # This script doesn't need to do anything on stop
        ;;
      *)
        echo "Usage: /etc/init.d/customhealthcheck {start|stop}"
        exit 1
        ;;
    esac
   
    exit 0
   

3. Make the Script Executable: Change the permissions of your script to make it executable.

    sudo chmod +x /etc/init.d/customhealthcheck
   

Step 2: Registering the Script with System Startup

1. Add the Script to Default Runlevels: Use the update-rc.d command to add your script to the system's startup sequences.

    sudo update-rc.d customhealthcheck defaults
   

2. Verify the Links: Verify that symbolic links have been created in the appropriate /etc/rcX.d/ directories for the runlevels you've chosen. For example, for runlevel 3, you would check in /etc/rc3.d/.

    ls /etc/rc3.d/ | grep customhealthcheck
   

   

Step 3: Testing the Script

1. Reboot Your System: To test that the script runs at startup, reboot your system.

    sudo reboot
   

2. Check the Log: After the system has restarted, check the /var/log/healthcheck.log file to confirm that your script executed and logged the disk usage.

    cat /var/log/healthcheck.log
   

   

This completes the hands-on challenge. You've written a custom startup script to perform a basic system health check, registered it with the system's startup sequence, and verified that it executes upon system boot. This exercise demonstrates how to integrate custom scripts into the SysVinit system, a foundational skill for Linux system administration.

References:

1. Vagrant Box devuan5

2. https://github.com/Brain2life/vagrant-templates/tree/devuan-vm-with-sysvinit