# Init system

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/init-system

## Quick definition

An init system is the core program that runs when your computer starts up. It is responsible for launching all other programs and services that make the operating system functional. Think of it as the chief organizer that decides what runs, when, and in what order. Without an init system, your computer would just sit at a blank screen after turning on.

## Simple meaning

When you press the power button on your computer, a lot happens behind the scenes before you see your desktop or login screen. One of the most important things that starts is called the init system. The name comes from 'initialization' because it is the very first program the computer's core (the kernel) launches. Once running, the init system takes over and becomes the parent of every other program or service on the system.

Think of a large office building with many departments. The init system is like the building manager who arrives first in the morning. This manager unlocks the doors, turns on the lights, starts the heating or cooling, and checks that the elevators work. Then, the manager ensures each department head is notified to start their teams. If a department has a problem, the manager decides whether to restart it or shut it down. At the end of the day, the manager oversees the orderly shutdown of all departments, making sure nothing is left running.

In the same way, the init system starts essential services such as the network connection, user login screens, and security features. It also monitors running services and can restart them if they fail. When you tell your computer to shut down or reboot, the init system gracefully stops everything in the correct order to avoid data loss or corruption. Two of the most common init systems are Systemd, used by many modern Linux distributions, and SysV init, an older but still-used system. Understanding how the init system works is crucial for anyone managing servers or troubleshooting startup problems.

## Technical definition

The init system is the first user-space process started by the kernel after booting, identified by process ID (PID) 1. It is responsible for bootstrapping the user environment, managing services (daemons), handling system states (runlevels or targets), and supervising child processes. In Linux, the kernel executes /sbin/init (or a symlink to it) as the initial process. If this process fails or is misconfigured, the system cannot reach a usable state.

There are two major init system architectures in common use: SysV init and Systemd. SysV init is the traditional System V Unix init, which uses a series of shell scripts located in directories such as /etc/rc.d/ or /etc/init.d. It relies on runlevels (0 through 6) to define system states: runlevel 0 is shutdown, 1 is single-user mode, 3 is multi-user with networking, 5 is multi-user with a graphical interface, and 6 is reboot. Services are started or stopped sequentially based on symbolic links in folders like /etc/rc3.d/. This sequential approach is simple but can be slow, especially on modern hardware with many services.

Systemd, designed to replace SysV init, uses parallel service startup, dependency-based ordering, and socket/timer activation. It uses 'units' (service, socket, target, timer, mount, automount, etc.) defined in files with a .service or .target extension, stored in /lib/systemd/system/ and /etc/systemd/system/. The primary command for interacting with Systemd is systemctl, which allows starting, stopping, enabling, disabling, and checking the status of services. Systemd introduces 'targets' instead of runlevels; for example, graphical.target is equivalent to runlevel 5, multi-user.target to runlevel 3, and poweroff.target to runlevel 0. Dependencies are expressed using directives like Requires, After, Before, and Wants.

Other init systems exist, such as Upstart (used by older Ubuntu versions) and OpenRC (used by Gentoo and Alpine). Upstart used job configuration files and event-driven startup. OpenRC is a dependency-based init system that works with the standard /etc/init.d scripts but adds parallel service startup and supervision.

In IT certification exams, you are expected to know the differences between SysV init and Systemd, how to manage services, how to change runlevels or targets, and how to troubleshoot boot issues. Understanding the boot process from BIOS/UEFI through bootloader (GRUB) to init is a common exam objective for Linux+ (XK0-005), LPIC-1, and RHCSA.

## Real-life example

Imagine you are organizing a large outdoor music festival. The festival grounds have multiple stages, food stalls, restrooms, security checkpoints, and medical tents. You are the festival director, and your job is to make sure everything is ready before the gates open. You arrive early in the morning and start turning on the main power generator (that's like the kernel starting the init system). Once the generator is running, you check that the lighting, sound systems, and water supply are working.

Next, you start the stage managers, security team, food vendors, and first aid staff in a specific order. You cannot start the bands playing until the sound system is tested and the stage is set up. Similarly, you cannot open the gates until security is in place. If one of the food vendors has a gas leak, you either fix it or shut that vendor down while the rest of the festival continues. At the end of the night, you oversee the shutdown: the bands stop playing, the food stalls close, the gates close, and finally, you turn off the generator.

This is exactly what an init system does. The festival director is PID 1. The stages and vendors are services. The order of startup is the dependency chain. If a service fails, the init system may restart it or log the failure. At shutdown, it ensures services stop gracefully. Just as a well-organized festival depends on a good director, a stable Linux system depends on a well-configured init system.

## Why it matters

The init system is the backbone of Linux system management. For IT professionals, understanding it is essential for troubleshooting boot failures, managing services, and automating system tasks. When a server does not start properly, the first step is often to check the init system logs using journalctl (for Systemd) or messages in /var/log/ (for SysV). Knowing how to change the default target or runlevel allows you to boot into a rescue mode to repair a broken system.

In production environments, init systems manage critical services like web servers, databases, and network connections. If the init system crashes, the entire system becomes unusable. Therefore, Red Hat and other enterprise distributions heavily rely on Systemd's features like service supervision, resource control, and logging. For DevOps and cloud engineers, container orchestration (like Docker and Kubernetes) also interacts with the host init system to manage processes and namespaces.

Security is another reason why init systems matter. They control which services start at boot and can enforce security policies like running services with limited privileges. Systemd, for instance, supports sandboxing options such as ProtectSystem, PrivateTmp, and NoNewPrivileges. This helps contain potential damage from compromised services.

From a certification standpoint, exam questions frequently test your ability to start, stop, restart, enable, disable, and query services. You may be asked to identify the correct command to change the default runlevel in SysV or to list the active targets in Systemd. Without a solid grasp of the init system, you risk losing points on questions about boot process, service management, and troubleshooting.

## Why it matters in exams

The init system is a core topic in several Linux certification exams, including CompTIA Linux+ (XK0-005), LPIC-1 (101-500 and 102-500), Red Hat Certified System Administrator (RHCSA), and the Linux Foundation Certified System Administrator (LFCS). In the CompTIA Linux+ exam, objectives cover 'Given a scenario, manage system services' and 'Explain the boot process'. You will encounter questions about using systemctl to enable or disable services, checking the status of a service, and determining what target the system is currently in.

For LPIC-1, the 101-500 exam includes a boot process and runlevels objective: 'Determine and configure the boot process, including the init system'. You need to know the SysV init runlevels, the /etc/inittab file, and how to use telinit to change runlevels. On the 102-500 exam, you may be asked about managing services in both SysV and Systemd contexts.

RHCSA exam requires deep practical knowledge of Systemd. You must be able to create custom systemd unit files, set dependencies, and use journalctl for logging. The exam may present a scenario where a service fails to start, and you need to troubleshoot by examining the unit file, checking logs, and fixing syntax errors.

Question types range from multiple-choice (e.g., 'Which command starts the httpd service immediately and enables it to start on boot?') to performance-based (e.g., 'Create a systemd service unit that runs a script after the network is up'). You may also see drag-and-drop questions about the boot sequence or matching runlevels to their descriptions. Understanding the init system also helps you answer troubleshooting questions where the system boots to a black screen or services fail to start after a configuration change.

## How it appears in exam questions

Exam questions about the init system typically fall into three categories: command syntax, boot process order, and troubleshooting scenarios.

Command syntax questions are very common. For example: 'Which command will display the status of the sshd service on a system using systemd?' The answer is systemctl status sshd. Another variation asks for the command to start a service immediately but not enable it to start on boot: systemctl start cups. Or to enable it on boot without starting it: systemctl enable cups. You might be given a SysV init question like: 'What command changes the default runlevel to runlevel 3?' The answer is editing /etc/inittab or using telinit 3 (but telinit changes the current runlevel, not the default).

Boot process order questions often show a list of steps and ask you to put them in the correct sequence. For example: BIOS -> Bootloader (GRUB) -> Kernel -> Init (PID 1) -> Systemd targets -> Service startup. You may need to identify that systemd runs before targets and that the /sbin/init file is a symlink to systemd.

Troubleshooting scenarios are more involved. A question might describe a situation: 'After a reboot, the nginx service does not start automatically, but manually starting it works fine. What could be the issue?' The answer is that the service is not enabled to start on boot, or there is a dependency problem. Another scenario: 'The system boots to a command line instead of the graphical interface. Which target should you set to restore the graphical login?' The answer is: set the default target to graphical.target using systemctl set-default graphical.target.

You might also see questions about log analysis: 'After a service fails to start, where can you find detailed error messages?' The correct answer for systemd is journalctl -u service_name. For SysV, it would be /var/log/messages or the service's own log file.

Understanding how to read unit files is increasingly common. For example, you may be shown a snippet of a .service file and asked what the Wants= network.target means. The answer: it indicates a soft dependency, meaning the service prefers the network to be up but will still start without it.

## Example scenario

You are a junior Linux administrator at a company that runs a web application on CentOS 7 using Systemd. The development team reports that the application server (running as a service called 'appserver') randomly stops and does not restart automatically. Your task is to ensure the service restarts automatically if it crashes.

First, you check the current status using systemctl status appserver. The output shows it is inactive (dead). You then view the unit file located at /etc/systemd/system/appserver.service. You notice that the [Service] section contains 'Restart=no'. You edit the file to change 'Restart=no' to 'Restart=always' and add 'RestartSec=5s' to wait 5 seconds before restarting. After modifying the file, you run systemctl daemon-reload to reload the configuration, then systemctl start appserver to start it again. You also run systemctl enable appserver to ensure it starts on boot.

To test, you kill the service process manually using kill -9 <PID> or systemctl kill appserver. The service immediately restarts after 5 seconds. You verify with systemctl status appserver and see that the active status shows 'active (running)' and the process has a new PID. This confirms the fix works.

In an exam, you might be asked what the Restart=always directive does or why you used systemctl daemon-reload. The answer: daemon-reload tells systemd to re-read the unit files because you changed the configuration while the service was loaded. Without it, your changes would not take effect until the next reboot.

This scenario ties together service management commands, unit file configuration, and troubleshooting-all key skills for Linux certification exams.

## Common mistakes

- **Mistake:** Thinking that systemctl start enables a service to start on boot.
  - Why it is wrong: systemctl start only starts the service right now but does not set it to start automatically on future reboots. You must also use systemctl enable.
  - Fix: Remember: start runs it now; enable makes it run on boot. Use both commands together when deploying a new service.
- **Mistake:** Editing a systemd unit file and forgetting to run systemctl daemon-reload.
  - Why it is wrong: Systemd caches the unit file contents in memory. If you edit the file but do not reload, the old configuration is still used. Changes will not take effect until you run daemon-reload or reboot.
  - Fix: After editing any unit file in /etc/systemd/system/, always run systemctl daemon-reload before starting or restarting the service.
- **Mistake:** Confusing SysV runlevels with Systemd targets on a system that uses systemd.
  - Why it is wrong: Runlevels are a SysV concept. Systemd uses targets. On modern distributions, commands like telinit or /etc/inittab are obsolete. Using them may work via compatibility but is not the proper way.
  - Fix: On a systemd-based system, use systemctl get-default and systemctl set-default to view or change the default target. Use systemctl isolate to switch to a different target.
- **Mistake:** Assuming all services have a unit file in /etc/systemd/system/.
  - Why it is wrong: Many default services have unit files in /lib/systemd/system/ instead. User-created or customized units should go in /etc/systemd/system/ to override defaults. Editing files in /lib/ is not recommended because they can be overwritten by package updates.
  - Fix: Always create custom unit files in /etc/systemd/system/. Use systemctl cat to see the full unit file location. If you need to override a default, use systemctl edit to create a drop-in snippet.
- **Mistake:** Using kill -9 to stop a service thinking it is safe for systemd services.
  - Why it is wrong: Killing a service with SIGKILL does not allow it to clean up resources (like temporary files or network connections). Systemd may not properly track the service state, leading to issues.
  - Fix: Always use systemctl stop or at least systemctl kill (which sends the proper signal). Reserve kill -9 for unresponsive processes as a last resort.

## Exam trap

{"trap":"The exam states that a system uses SysV init and asks you to change the default runlevel to runlevel 5. You select 'telinit 5' as the answer.","why_learners_choose_it":"Learners know that telinit changes the current runlevel, and they mistakenly think it also changes the default runlevel for future boots. The command looks similar to systemctl isolate or init q.","how_to_avoid_it":"Remember that telinit changes the current runlevel only. To change the default runlevel on a SysV init system, you must edit the /etc/inittab file and set the initdefault line. In systemd, use systemctl set-default graphical.target. Pay close attention to whether the question asks for 'current' or 'default'."}

## Commonly confused with

- **Init system vs Bootloader:** The bootloader (like GRUB) is the program that loads the Linux kernel into memory. The init system is started by the kernel after the bootloader finishes. The bootloader does not manage services; its only job is to hand off control to the kernel. (Example: GRUB lets you choose which kernel to boot, but once the kernel starts, GRUB is done. The init system then takes over and starts everything else.)
- **Init system vs Service manager:** While the init system often includes a service manager component (like systemd's systemctl), not all init systems are full service managers. SysV init is primarily a boot sequencer; actual service management is handled by scripts. Systemd integrates both roles into one daemon. (Example: SysV init uses separate scripts in /etc/init.d/ to manage services, while systemd uses its own unit file system and the systemctl command.)
- **Init system vs Daemon:** A daemon is a background process (e.g., httpd, sshd) that runs continuously. The init system is the parent process that launches and monitors daemons. Daemons are children of init, not the init system itself. (Example: The SSH daemon (sshd) is a service that runs in the background. The init system decides when to start it, and if it crashes, the init system may restart it.)
- **Init system vs Supervisor process:** Supervisor processes like monit or supervisord are user-space tools that monitor and restart specific services. They are not the first process (PID 1) and do not handle system boot or shutdown. They run on top of the init system. (Example: You might use supervisord to keep a Python web app running, but supervisord itself is started by systemd.)

## Step-by-step breakdown

1. **BIOS/UEFI initialization** — When you power on the computer, the BIOS or UEFI firmware runs hardware checks and identifies the boot device (e.g., hard disk, SSD). It then loads the bootloader from the Master Boot Record (MBR) or EFI System Partition (ESP). This is the first code that runs, but it has no concept of an init system yet.
2. **Bootloader execution** — The bootloader (most commonly GRUB on Linux) loads the kernel and an initial RAM disk (initramfs) into memory. It passes control to the kernel by jumping to its entry point. The bootloader may also pass kernel parameters (e.g., single for single-user mode).
3. **Kernel startup and initramfs** — The kernel starts up, mounts the temporary root filesystem from initramfs, and loads necessary drivers (e.g., for disk controllers, filesystem modules). Once the real root filesystem is accessible, the kernel mounts it and then executes the init program at /sbin/init. This is the first user-space process, with PID 1.
4. **Init system takes over (PID 1)** — The init system (SysV, systemd, or other) reads its configuration files. Systemd reads unit files and determines the default target. SysV reads /etc/inittab to find the default runlevel. The init system then starts essential services like udev (device manager), filesystem checks, networking, and logging.
5. **Service and target startup** — The init system launches all enabled services. In Systemd, units are started in parallel based on dependency ordering. For example, network.target must be reached before a web server that Requires=network.target. SysV starts scripts sequentially in alphabetical order from the rc directory. Once the default target is reached, the system presents a login prompt or graphical interface.
6. **System operation and service supervision** — The init system continues running as PID 1 throughout the uptime. It monitors child processes. If a service crashes, systemd can restart it based on Restart= policy. SysV init does not supervise services-it just starts them and leaves them alone. The init system also handles signals like SIGTERM during shutdown.
7. **System shutdown or reboot** — When you issue shutdown or reboot, the init system sends SIGTERM to all processes, waits for them to exit, unmounts filesystems, and then either halts the CPU or reboots. Systemd uses its own shutdown logic with targets like poweroff.target. SysV uses runlevel 0 (halt) or 6 (reboot) scripts.

## Practical mini-lesson

In real-world system administration, you will interact with the init system daily, whether you realize it or not. Every time you install a web server, set up a database, or configure a scheduled task, you are working with the init system. On a Systemd-based distribution, the primary tool is systemctl. Understanding its subcommands is critical.

To list all active services: systemctl list-units --type=service --state=running. To list all installed unit files: systemctl list-unit-files. To see dependencies: systemctl list-dependencies sshd. To check if a service is enabled: systemctl is-enabled sshd. To see the boot time of the last boot: systemd-analyze. To see which services took longest to start: systemd-analyze blame.

Creating a custom systemd service is a common task. You write a .service file with three sections: [Unit] for metadata and dependencies, [Service] for the execution parameters (ExecStart, ExecStop, Restart, User, Group, etc.), and [Install] for enabling (WantedBy). For example, a simple service to run a Python script might look like:
[Unit]
Description=My Python App
After=network.target

[Service]
ExecStart=/usr/bin/python3 /opt/myapp/app.py
Restart=always
User=myappuser

[Install]
WantedBy=multi-user.target

After placing this file in /etc/systemd/system/myapp.service, you run systemctl daemon-reload, then systemctl enable myapp and systemctl start myapp.

What can go wrong? Common issues include incorrect file permissions (systemd requires 644 for unit files), syntax errors in ExecStart (paths must be absolute), missing dependencies (Wants vs. Requires), and failure to create the user specified in the service. Always check the journal with journalctl -u myapp to see detailed error messages.

For SysV init, you would instead create an init script in /etc/init.d/ and use chkconfig to manage runlevels. The script must support start, stop, status, and restart arguments. Modern certification exams focus heavily on Systemd, but you should still know basic SysV commands like service sshd status and chkconfig --list.

Understanding init systems also helps with container troubleshooting. Docker containers typically run a single process, but if you need to run multiple services inside a container, you might use a minimal init system like tini or s6 to handle signal propagation and zombie reaping. This is an advanced topic but shows how core the concept is.

## Memory tip

Remember: PID 1 is always the init system. Use 'systemctl' to control systemd services.

## FAQ

**What is the difference between systemctl start and systemctl enable?**

systemctl start launches a service immediately but does not affect whether it starts automatically on boot. systemctl enable configures the service to start at boot. Use both together for persistent services.

**Can I have both SysV init and systemd on the same system?**

Technically, they are mutually exclusive as PID 1. However, systemd provides compatibility with SysV init scripts by running them through a compatibility layer. You cannot run both as the primary init system.

**How do I change the default target in systemd?**

Use systemctl set-default <target>. For example, systemctl set-default multi-user.target sets the system to boot to command line. To see the current default, run systemctl get-default.

**What is the purpose of systemctl daemon-reload?**

It tells systemd to re-read all unit files from disk into memory. You must run this after making changes to any unit file so that systemd uses the updated configuration without requiring a reboot.

**Why is PID 1 special?**

PID 1 is the first process started by the kernel. It is the ultimate parent of all other processes. If PID 1 dies, the kernel panics and the system crashes. It also handles reaping orphaned child processes.

**What is an initramfs and how does it relate to the init system?**

An initramfs (initial RAM filesystem) is a temporary root filesystem loaded by the kernel. It contains the tools and drivers needed to mount the real root filesystem. Once the real root is mounted, the init system (PID 1) is executed from there.

**Does Windows have an init system?**

Windows has a similar concept called the Session Manager Subsystem (smss.exe) and the Service Control Manager (services.exe). They are not called init systems, but they serve analogous roles in booting and managing services.

## Summary

The init system is a foundational component of Linux operating systems, acting as the first process (PID 1) launched by the kernel. It is responsible for initializing the user space, starting and monitoring services, managing dependencies, and orchestrating graceful shutdowns. Understanding the init system is crucial for IT professionals because it touches every aspect of system administration, from boot troubleshooting to service management. The two primary init systems encountered in certification exams are SysV init and Systemd, with Systemd being the modern standard on most enterprise distributions. Common exam topics include using systemctl commands to manage services, understanding runlevels versus targets, editing unit files, and troubleshooting boot failures. Many mistakes stem from confusion between the start/enable commands, forgetting to reload unit files after edits, and misidentifying the init system in use. By mastering the init system, you gain a deeper understanding of how Linux operates and become better equipped to handle real-world server environments. For certification success, focus on hands-on practice with service management commands, dependency configuration, and log analysis using journalctl.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/init-system