# systemd

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/systemd

## Quick definition

systemd is the first program that runs when a Linux computer starts up, and it takes care of launching everything else, like network connections, user login screens, and background services. It replaces older startup systems like SysVinit with faster, more modern management. You interact with it using simple commands like systemctl to start, stop, or check the status of services.

## Simple meaning

Imagine a large office building that needs to open every morning. There is a building manager who arrives first, unlocks the doors, turns on the lights, starts the heating or air conditioning, and makes sure the coffee machine is working. That manager also keeps an eye on everything during the day, turning off lights in empty rooms and restarting the printer if it jams. In the world of Linux, systemd is that building manager for your computer. 

 When you press the power button, the Linux kernel starts first, like the building's foundation. Then systemd takes over as the very first user-space process, with process ID 1. It reads a set of configuration files that tell it what needs to run and in what order. For example, it starts the network service so you can go online, the display manager so you can see your desktop, and SSH so you can connect remotely. It also manages dependencies, meaning if one service depends on another, systemd waits for the first one to be ready before starting the second. 

 systemd does not just start services. It also monitors them while the system is running. If a service crashes, systemd can restart it automatically. If a service freezes, you can ask systemd to kill it and start a fresh copy. It keeps a detailed journal, or log, of everything that happens, which helps you troubleshoot problems later. Because systemd handles so many tasks, it has become the standard on nearly all modern Linux distributions, including Ubuntu, Fedora, Debian, and CentOS.

## Technical definition

systemd is a software suite with a central component that serves as the init system (PID 1) on Linux-based operating systems. It was designed to address shortcomings of the traditional SysVinit and Upstart init systems, such as serial startup, poor dependency handling, and lack of parallelization. systemd introduces the concept of units, which are configuration files that define system resources such as services, sockets, mount points, devices, timers, and targets. Each unit file contains directives that specify how and when that unit should be started, stopped, and on what other units it depends. 

 The key binaries within the systemd suite include systemd (the init daemon), systemctl (the primary control command), journalctl (for querying the systemd journal), and systemd-analyze (for analyzing boot performance). Units are stored in /usr/lib/systemd/system/ (vendor-supplied), /etc/systemd/system/ (local overrides), and /run/systemd/system/ (runtime definitions). A unit file is a plain-text file with sections like [Unit] for metadata and dependencies, [Service] for how to start/stop the program, and [Install] for enabling the service at boot. 

 systemd uses socket-based activation to start services only when they are actually needed, and it uses parallel startup to boot the system faster by launching independent units simultaneously. It also implements cgroups (control groups) for resource management, allowing systemd to track and limit CPU, memory, and I/O usage per service. The systemd journal stores binary log data in /var/log/journal/ and supports structured logging, timestamp indexing, and automatic log rotation. systemd also manages the system's target system, which is similar to runlevels in SysVinit, with common targets like multi-user.target (non-graphical), graphical.target (with a desktop), and rescue.target (minimal emergency shell). 

 In practice, IT professionals use systemd heavily in server environments. For example, to create a custom service, you write a .service unit file, place it in /etc/systemd/system/, run systemctl daemon-reload, then systemctl enable and start your-service. To troubleshoot a failing service, you check its status with systemctl status, view its logs with journalctl -u, and adjust resource limits by adding directives like MemoryMax= or CPUQuota= in the unit's [Service] section. systemd has become a de facto standard across most major Linux distributions, making it a critical skill for Linux system administrators.

## Real-life example

Think of systemd as an air traffic control tower at a busy international airport. The airport's runways and gates are like your computer's hardware, and each airplane is a service or program that needs to get to its destination. When the airport opens in the morning (the system boots), the control tower operators (systemd) do not just tell all planes to take off at once. That would cause chaos, with planes colliding on the runway. Instead, they have a detailed schedule and a set of rules. 

 For example, the first plane might be the baggage handling system, which needs to be running before any passenger plane can load luggage. The next might be the fuel trucks, which need to be ready before a plane can refuel. The control tower starts these support services first, in the right order, and only when they confirm they are ready do they give clearance for the passenger planes to begin boarding. This is exactly how systemd handles dependencies. A web server service might depend on the network being up and the database service running. systemd waits for the network and database before starting the web server. 

 Later in the day, if a plane encounters a mechanical problem, the control tower can instruct it to return to the gate (restart) or tow it away (stop). systemd does the same thing when a service crashes. The tower also records every communication and movement in a log, so if there is a question about why a flight was delayed, they can review the recordings. That is what journalctl does. Without the control tower, every plane would just try to take off at the same time, causing gridlock. Before systemd, older Linux init systems often started services one by one, serially, which was slow and inefficient. systemd brought order, speed, and reliability to Linux booting and service management.

## Why it matters

For IT professionals, understanding systemd is not optional, it is a fundamental skill for managing any modern Linux server or desktop. Almost every major Linux distribution, from Red Hat Enterprise Linux and CentOS to Ubuntu and Debian, now uses systemd as the default init system. This means that when you are administering servers, you will use systemctl commands constantly to start, stop, restart, enable, and disable services. You will rely on journalctl to view logs and diagnose issues. You will create custom service files to run your own applications in production. 

 systemd also brings important performance and reliability benefits. Its parallel startup shortens boot times, which is critical for servers that need to come online quickly after a power outage or maintenance reboot. Its automatic service restart feature can keep critical applications running even if they crash, reducing downtime. The use of cgroups helps prevent runaway processes from consuming all system resources, which is especially important on multi-tenant servers or containers. 

 From a troubleshooting perspective, systemd provides rich diagnostic tools. When a service fails to start, systemctl status will often tell you exactly why, with a descriptive error message and a hint about the fix. The journal captures not just standard logs but also kernel messages, making it a single source of truth for system debugging. In exam contexts and real-world scenarios, employers and certification bodies expect you to know how to interact with systemd. It is a core topic for Linux+ (XK0-005), RHCSA (EX200), and many other exams. Ignoring systemd is like a mechanic not knowing how to use a socket wrench.

## Why it matters in exams

systemd is a core objective for multiple IT certification exams, and it appears frequently in both multiple-choice questions and performance-based tasks. For the CompTIA Linux+ (XK0-005) exam, systemd is listed under domain 4.0 (Operations Management), with objectives covering managing services with systemctl, viewing logs with journalctl, creating and modifying unit files, and understanding targets and dependencies. Expect questions about the correct command to start a service permanently, the difference between enable and start, and how to override a service's startup options. 

 For the Red Hat Certified System Administrator (RHCSA) exam (EX200), systemd is essential. The exam requires you to configure services to start at boot, modify service parameters using drop-in files, and use systemctl to manage service states. You may be asked to create a custom systemd service that runs a script at startup, or to modify an existing service to run under a specific user or with specific resource limits. The EX200 is a hands-on practical exam, so you must know exactly where unit files are stored and how to reload the daemon after changes. 

 On the Linux Professional Institute (LPI) exams, such as LPIC-1 (101 and 102), systemd is covered in topics related to system boot, service management, and logging. Questions may ask about the purpose of the systemd journal, how to use journalctl with filters, and the difference between SysVinit and systemd runlevels. 

 In all these exams, common traps include confusing systemctl start with systemctl enable, forgetting to run systemctl daemon-reload after modifying unit files, and thinking that disabling a service stops it immediately (it does not, you must also stop it). Another frequent trick is presenting a legacy SysVinit command and asking what the systemd equivalent is, such as chkconfig vs systemctl enable. Mastering systemd commands and concepts will directly boost your exam score.

## How it appears in exam questions

systemd questions in IT exams come in several patterns. The first and most common is the command-based multiple-choice question: Which command is used to start a service immediately and enable it to start on boot? The correct answer is systemctl enable --now service_name, but many learners forget the --now flag. Another common question type asks about unit files: Where are user-created or modified systemd unit files stored? The answer is /etc/systemd/system/, as opposed to the vendor location /usr/lib/systemd/system/. 

 Scenario-based questions are also frequent. For example: A server runs a custom Python application. The administrator wants it to restart automatically if it crashes, and also to start automatically after a system reboot. The candidate must know to create a .service unit file with Restart=on-failure and [Install] section with WantedBy=multi-user.target, then run systemctl enable and start. 

 Troubleshooting questions often present a failing service. Example: You run systemctl status nginx and see the string (code=exited, status=1/FAILURE). What is the most likely cause? The answer might be a syntax error in the nginx config file. Then they ask: Which command would you use to see the specific error messages? The correct answer is journalctl -u nginx. 

 Another common question tests knowledge of targets: Which target is the default for a server without a graphical desktop? multi-user.target. Or: Which command shows the default target? systemctl get-default. Performance questions about boot time might ask: Which command analyzes the boot process to show which services take the longest to start? systemd-analyze blame. 

 Finally, there are comparison questions: What is the main advantage of systemd over SysVinit? The correct answer is parallel startup and better dependency handling. The exam may also present a SysVinit command like service iptables start and ask for its systemd equivalent: systemctl start iptables. Understanding these patterns is key to scoring well.

## Example scenario

You are a junior Linux administrator at a small company. Your manager tells you that the company's internal wiki, which runs on a Debian server, has not been starting properly after the monthly patching reboots. She asks you to investigate and fix it so the wiki comes up automatically every time the server restarts. 

 First, you SSH into the server and check the current status of the wiki service. You type systemctl status wiki and see that it is inactive and not enabled. That means it is not configured to start on boot. Next, you list the unit files to see if a wiki.service file exists by running systemctl list-unit-files | grep wiki. You find it exists but is disabled. 

 You decide to enable it so it starts automatically on boot. You run sudo systemctl enable wiki. The system confirms a symlink was created. Then you start the service immediately with sudo systemctl start wiki. You verify success by running systemctl status wiki again to make sure it shows active (running) and no errors. 

 But you are not done yet. To be thorough, you simulate a reboot by checking the boot sequence. You run systemd-analyze to see overall boot time, then systemd-analyze blame to verify the wiki service starts in a reasonable timeframe. Finally, you test the wiki by opening it in a browser. It loads perfectly. You document your steps in a ticket and add a note to check the service after the next patch cycle just to be safe. This scenario demonstrates the core systemd skills of service management, enabling, starting, and verification.

## Common mistakes

- **Mistake:** Using 'systemctl start' to make a service start on boot
  - Why it is wrong: The 'start' command only starts the service right now, but it does not enable it to start automatically after a reboot. Many learners think starting a service makes it permanent.
  - Fix: Use 'systemctl enable' to create the symlink for boot-time startup. Use 'systemctl enable --now' to both enable and start in one command.
- **Mistake:** Editing a unit file in /usr/lib/systemd/system/ for custom configurations
  - Why it is wrong: Files in /usr/lib/systemd/system/ are managed by the package manager and can be overwritten on updates. Custom changes there will be lost.
  - Fix: Place custom unit files or override configurations in /etc/systemd/system/. Use 'systemctl edit unit_name' to create a drop-in override safely.
- **Mistake:** Forgetting to run 'systemctl daemon-reload' after modifying a unit file
  - Why it is wrong: systemd caches unit file information. If you change a file and then try to start the service, systemd may still use the old configuration or fail to recognize the new directives.
  - Fix: Always run 'sudo systemctl daemon-reload' after manually editing any unit file, then 'systemctl restart service_name' to apply changes.
- **Mistake:** Confusing 'disable' with 'stop'
  - Why it is wrong: Disabling a service only removes it from the boot sequence; it does not stop a currently running service. Learners often disable a service expecting it to halt immediately.
  - Fix: To stop a running service immediately, use 'systemctl stop service_name'. To also prevent it from starting at boot, follow with 'systemctl disable service_name'. Use 'systemctl disable --now' to do both.
- **Mistake:** Using 'kill' or 'service stop' instead of 'systemctl stop'
  - Why it is wrong: Older SysVinit commands may work on some systems but are inconsistent. systemd tracks services via cgroups, so killing a process directly may leave the service in a confused state.
  - Fix: Always use 'systemctl stop service_name' to cleanly terminate the service and update systemd's state.

## Exam trap

{"trap":"The exam asks: 'Which command makes a service start automatically at boot?' and lists options like 'systemctl start', 'systemctl enable', 'systemctl boot', and 'systemctl status'.","why_learners_choose_it":"Learners see the word 'start' in 'systemctl start' and think starting a service once will also make it start on boot. They may not remember the specific role of 'enable'.","how_to_avoid_it":"Remember: 'start' is immediate only. 'enable' creates the symlink for boot. The phrase 'start at boot' is a direct clue for 'enable'. Practice using both together: 'systemctl enable --now service'."}

## Commonly confused with

- **systemd vs init (SysVinit):** SysVinit is the older init system that uses /etc/inittab and runs scripts sequentially from /etc/rc.d/. systemd uses parallel startup, unit files, and targets instead of runlevels. SysVinit commands like 'service' and 'chkconfig' are deprecated on systemd systems. (Example: To check if a service is running on a SysVinit system, you would type 'service httpd status'. On a systemd system, you type 'systemctl status httpd'.)
- **systemd vs supervisord:** supervisord is a process control system focused on managing individual programs, often used in Python environments. Unlike systemd, it does not handle boot sequencing, dependency management, or logging on a system-wide level. systemd can replace supervisord for many use cases. (Example: If you want a simple background worker to restart if it crashes, you could use either. But systemd is already on the system and integrates with the rest of the OS.)
- **systemd vs upstart:** Upstart was an event-based init system used by Ubuntu before adopting systemd. It used configuration files with a different syntax and job definitions. systemd is more widely adopted, more feature-rich, and is the current standard across most distributions. (Example: Under Upstart, you might use 'initctl start myjob'. Under systemd, you use 'systemctl start myjob'. Learning systemd is more valuable for current certifications.)
- **systemd vs cron:** cron is a time-based job scheduler that runs commands at specified intervals. systemd has its own timer units that can replace cron for many tasks. Unlike cron, systemd timers can run jobs even if the system was off at the scheduled time, and they provide better logging and dependency integration. (Example: To run a cleanup script nightly, you can create a cron job in /etc/crontab, or you can create a .timer unit paired with a .service unit in systemd.)

## Step-by-step breakdown

1. **Kernel Initialization** — After the BIOS or UEFI hands off control, the Linux kernel loads and initializes hardware drivers. As the last step of kernel initialization, it starts systemd as the first user-space process (PID 1). This is the critical handoff point.
2. **systemd Reads Unit Files** — systemd loads all unit files from predefined directories (/etc/systemd/system/, /usr/lib/systemd/system/, and /run/systemd/system/). These files define services, sockets, targets, timers, and other resources. systemd resolves dependencies between units to determine the startup order.
3. **Activation of default.target** — systemd activates the default target, which is usually multi-user.target (no GUI) or graphical.target (with GUI). This target pulls in all dependent units in parallel, such as basic.target, network.target, and local-fs.target, ensuring essential services are started first.
4. **Parallel Service Startup** — systemd starts services concurrently based on their dependencies. For example, the network service and the local file system check can start at the same time because they are independent. This parallelization significantly reduces boot time compared to the serial startup of SysVinit.
5. **Monitoring and Logging** — Once services are running, systemd monitors them using cgroups. If a service crashes, systemd can restart it automatically if configured with Restart=on-failure. All output from services is captured by the systemd journal, which can be queried with journalctl.
6. **Shutdown Sequence** — When the system shuts down or reboots, systemd stops all running services in reverse order of their startup. It sends SIGTERM first, waits a configurable timeout, then sends SIGKILL. This ensures a clean shutdown and proper flushing of cached data.

## Practical mini-lesson

systemd is not just a service manager; it is a complete system management framework. As an IT professional, your daily interaction with systemd will revolve around three main areas: service lifecycle management, journal log analysis, and custom unit creation. 

 For service lifecycle, master these commands: systemctl start, stop, restart, enable, disable, status, is-active, is-enabled. Remember that start and stop affect only the current runtime state. Enable and disable control the boot-time behavior. The --now flag lets you combine them, like systemctl enable --now sshd to start and enable in one go. Use systemctl list-units --type=service --state=running to see all running services. 

 Journalctl is your diagnostic powerhouse. Without any options, it shows all logs from the current boot. To see logs for a specific service, use journalctl -u service-name. For logs from the last boot, use journalctl -b -1. To follow logs live, use journalctl -f. You can also filter by priority, time, or unit. The journal is persistent across reboots if /var/log/journal/ exists. On some systems, you may need to create it manually with mkdir -p /var/log/journal and restart systemd-journald. 

 Creating a custom service is a routine task. Start with a simple backup script: create a file /etc/systemd/system/myscript.service with content that includes [Unit] Description=My backup script, [Service] Type=simple ExecStart=/usr/local/bin/backup.sh, [Install] WantedBy=multi-user.target. After saving, run systemctl daemon-reload to tell systemd about the new file. Then enable and start it. If your script needs to run periodically, you can pair it with a timer unit instead of cron. Create myscript.timer with OnCalendar=daily, then enable and start the timer. systemd handles missed runs and provides reliable logging. 

 Common pitfalls include forgetting to make your script executable, using an absolute path for ExecStart, and not setting proper permissions. Always test with systemctl start myscript and check status. If it fails, journalctl -u myscript will show you the error. Over time, you will appreciate how systemd standardizes and simplifies service management across all your Linux systems.

## Commands

```

```


```

```


```

```


```

```


```

```


```

```


```

```


```

```


```

```


```

```


## Troubleshooting clues

- **undefined** — symptom: undefined. undefined
- **undefined** — symptom: undefined. undefined
- **undefined** — symptom: undefined. undefined
- **undefined** — symptom: undefined. undefined
- **undefined** — symptom: undefined. undefined
- **undefined** — symptom: undefined. undefined

## Memory tip

Remember "Start now, Enable forever", the phrase pairs start with immediate action and enable with persistent boot behavior.

## FAQ

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

systemctl start runs a service immediately, but it will not automatically start after a reboot. systemctl enable creates a symlink so the service starts at boot, but it does not start it right away. Use systemctl enable --now to do both.

**Where are systemd unit files stored?**

Unit files are stored in three locations: /usr/lib/systemd/system/ for package-installed units, /etc/systemd/system/ for user-created or overridden units (this takes precedence), and /run/systemd/system/ for runtime units.

**What does 'systemctl daemon-reload' do?**

It tells systemd to reload its unit file cache. If you modify or add a .service file, you must run daemon-reload before systemd recognizes the changes.

**How do I make a service restart automatically if it crashes?**

Add the line 'Restart=on-failure' in the [Service] section of the unit file. Optionally set 'RestartSec=5' to wait 5 seconds before restarting.

**What is the systemd journal and how do I use it?**

The systemd journal is a binary log system that captures logs from the kernel and all services. Use 'journalctl' to view it, 'journalctl -u service-name' for logs from a specific service, and 'journalctl -f' to follow new log entries in real time.

**Can I use systemd without being root?**

Some systemctl commands, like checking service status or viewing the journal, can be run as a regular user. However, commands that start, stop, enable, or disable services typically require superuser privileges via sudo.

**What is a target in systemd?**

A target is a group of units that should be started together to reach a certain system state. For example, multi-user.target starts all services needed for a multi-user text-mode environment. It is similar to a runlevel in SysVinit.

## Summary

systemd is the modern init system and service manager for Linux, responsible for booting the system, managing services, and handling logging. It replaced older systems like SysVinit and Upstart with faster parallel startup, better dependency management, and powerful tools like systemctl and journalctl. For IT professionals, mastering systemd is essential for administering servers, troubleshooting issues, and preparing for certifications like CompTIA Linux+, RHCSA, and LPIC-1. 

 Key takeaways include remembering the difference between start and enable, always running daemon-reload after editing unit files, and using journalctl as your primary log viewer. The common exam traps involve confusing immediate commands with persistent ones, and forgetting to reload the daemon. 

 In real-world practice, you will create custom services, manage service dependencies, and rely on systemd's automatic restart features to keep critical applications running. Whether you are a beginner or advancing toward system administration, understanding systemd is a cornerstone of Linux proficiency.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/systemd