LFCA 33 🐧 What System Services Are
A Linux system is not just a kernel and a shell. It is a collection of long-running programs that start at boot, run in the background, and provide the system’s capabilities: networking, logging, time synchronization, remote access, scheduled tasks, hardware management. These programs are system services — daemons in the traditional Unix vocabulary. A service is a program that runs without a terminal, manages its own lifecycle, and typically responds to requests rather than performing a single task and exiting. Every SSH connection, every web request, every log entry, every scheduled backup depends on a service that is running. This chapter covers what a service is, how it differs from a regular process, the lifecycle that services follow, the init systems that manage them, the concepts of dependency and ordering, and the reasons services fail. It is the foundation for the next chapter, which covers the commands for managing services.
Key point: A system service is a long-running background process that provides a capability to the system. Services are managed by an init system — traditionally SysV init, but systemd on almost every modern distribution. The init system starts services at boot, supervises them while the system runs, restarts them if they fail, and stops them at shutdown. Each service is defined by a unit or an init script that declares what to run, what it depends on, and how it should behave. Services typically run as dedicated system users (not root, and not the invoking user), log to the system journal or to their own files, and communicate through sockets, files, or the D-Bus. The unit’s dependencies determine the order in which services start.
Why services exist
A Linux system has work that must happen continuously and independently of any user. The network must be configured before anything can use it. The logger must be running before anything can log. The scheduler must be running before the cron jobs fire. The SSH daemon must be listening before anyone can connect remotely. None of these has a natural end; they run for as long as the system is up.
The distinction from a command. A command runs, does its work, and exits. A service starts and stays running. ls is a command; sshd is a service. The command has a beginning and an end; the service has only a beginning until the system shuts down or the service is stopped.
The distinction from a user process. A user process is started by a user and runs with that user’s privileges and environment. A service is started by the init system at boot, runs with a dedicated user’s privileges, and has no dependency on any login session. The service is a system-level process; the user process is a session-level one.
Why services need a manager. Something has to start the services in the right order, monitor them, restart them on failure, and stop them on shutdown. On early Unix systems, this was init and the shell scripts in /etc/init.d. On modern systems, it is systemd and the unit files. The manager is the system’s supervisor, and services are what it supervises.
Why services are the system’s interface. Almost every capability the system provides is a service. Networking is NetworkManager or systemd-networkd. Logging is systemd-journald. Time is systemd-timesyncd or chronyd. Remote access is sshd. Scheduled tasks are cron or systemd-timers. Web serving is nginx or apache2. The system is the collection of its services, and knowing which services are running is knowing what the system can do.
Why the service model matters for administrators. A service that fails to start breaks whatever capability it provides. A service that crashes and is not restarted leaves the capability broken until someone notices. The init system’s job is to detect the failure and respond. The administrator’s job is to configure the services, understand their dependencies, and diagnose the failures.
Why “daemon” and “service” are nearly synonyms. A daemon is a background process that is not associated with a terminal. A service is a daemon managed by the init system. Every service is a daemon, but a daemon started manually is not a service. The names are often used interchangeably, and the difference is whether the init system is aware of it.
The characteristics of a service
Services share a set of behaviors that distinguish them from ordinary programs.
They run without a controlling terminal. A service is detached from any terminal. It has no stdin, and its stdout and stderr are redirected to a log or to /dev/null. This is what makes it a daemon. The detachment is what allows it to run independently of any login session.
They run as a dedicated user. Most services run as a system user that was created for them — www-data for a web server, sshd for the SSH daemon, systemd-network for the network manager. Running as a non-root user is the principle of least privilege: the service has only the permissions it needs. The user is created during the package installation and has no login shell.
They have a well-defined lifecycle. A service is started, runs, and is stopped. The init system manages the transitions. The service may also support reload, which re-reads its configuration without restarting, and restart, which stops and starts it in sequence.
They log to a standard location. Traditional services log to their own files under /var/log. Modern services log to the system journal, which is managed by systemd-journald. The journal collects the output of every service and makes it queryable with journalctl. The choice is per service, and the configuration determines where the logs go.
They communicate through defined channels. A service may listen on a network socket (sshd, nginx), on a Unix socket (the Docker daemon, the D-Bus), or on the D-Bus. The channel is what other programs use to talk to the service. The channel is declared in the service’s configuration, and the firewall rules determine who can reach it.
They are defined by a configuration file. The service’s behavior is controlled by a configuration file — /etc/ssh/sshd_config for sshd, /etc/nginx/nginx.conf for nginx, /etc/systemd/system/*.service for the systemd unit. The configuration is read at start and, for services that support it, at reload.
Why the characteristics matter. Each one is a question the administrator asks when a service misbehaves: Is it running? As which user? With which configuration? Logging where? Listening on what? The answers are the service’s identity, and the init system’s commands and the service’s configuration file are where the answers live.
The init system
The init system is the first process the kernel starts (PID 1) and the last process to stop. Its job is to bring the system to a usable state at boot, to supervise the services while the system runs, and to shut them down cleanly at shutdown.
SysV init. The traditional init system. It reads /etc/inittab, runs the scripts in /etc/init.d/ in the order determined by the runlevel, and the scripts are numbered links in /etc/rc*.d/. The scripts are shell scripts, and the ordering is by the numeric prefix — S20networking starts before S50sshd. SysV init is simple and predictable, but it is slow (the services start sequentially), it does not restart failed services, and it does not track dependencies beyond the numbering convention.
systemd. The modern init system, used by Debian, Ubuntu, Fedora, RHEL, openSUSE, Arch, and almost every other distribution. It starts services in parallel where possible, tracks dependencies explicitly, restarts failed services, and provides a rich set of commands for querying and controlling them. The units are declarative configuration files under /etc/systemd/system/ and /usr/lib/systemd/system/. The systemctl command is the interface.
Upstart. A transitional init system used by Ubuntu before it moved to systemd. It is event-driven rather than runlevel-driven. It is now historical and appears only on old systems.
Why the init system matters. The choice determines the commands the administrator uses, the format of the service definitions, the way the dependencies are expressed, and the tools for querying the service state. A modern system uses systemctl; an old one uses service and chkconfig or update-rc.d. The commands are different, but the concepts are the same.
Why systemd won. It starts services in parallel, which makes boot faster. It tracks dependencies explicitly, which makes the ordering correct rather than conventional. It restarts failed services, which makes the system more resilient. It provides journalctl for querying the logs of every service in one place. It manages timers, sockets, mounts, and more, not just services. The adoption was not unanimous — some administrators prefer the simplicity of SysV — but it is now the default on almost every distribution.
Why a service can be started outside the init system. A program can be run directly from the shell and it will run as a process, but it is not a service. The init system does not know about it, so it is not restarted on failure, not started at boot, and not stopped at shutdown. Running a service outside the init system is a temporary measure, and the nohup and setsid from the previous chapter are the tools for it.
Why the “PID 1 problem” matters for containers. In a Docker container, the process that runs as PID 1 is the container’s init. If it is the application itself, the application has to handle the responsibilities of init — reaping zombies, forwarding signals. If it is a full init system, the container is heavier. This is why small init programs like
tiniexist for containers. The concept of init is not specific to the host; it is the first process of any process tree.
Units and service definitions
A service is defined by a configuration that declares what to run, how to run it, and what it depends on. In systemd, this is a unit file; in SysV, it is an init script and a set of symlinks.
The systemd unit file. A unit file is a plain-text file with a .service extension, organized in sections.
[Unit]
Description=OpenSSH server daemon
Documentation=man:sshd(8) man:sshd_config(5)
After=network.target sshd-keygen.target
Wants=sshd-keygen.target
[Service]
Type=notify
EnvironmentFile=-/etc/sysconfig/sshd
ExecStart=/usr/sbin/sshd -D $OPTIONS
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartSec=42s
[Install]
WantedBy=multi-user.targetThe [Unit] section declares metadata and dependencies. The [Service] section declares how to run the program. The [Install] section declares what happens when the service is enabled.
Why the unit file is declarative. The file describes the desired state — the program, its dependencies, its restart policy — and systemd does the work of starting it, monitoring it, and restarting it. The administrator describes what should happen; systemd handles how.
The key [Service] directives.
| Directive | Purpose |
|---|---|
ExecStart | The command to run |
ExecStop | The command to stop it |
ExecReload | The command to reload config |
Restart | When to restart (always, on-failure, no) |
User / Group | The user to run as |
WorkingDirectory | The working directory |
Environment / EnvironmentFile | Environment variables |
Type | How systemd detects startup (simple, forking, notify, oneshot) |
The Type directive is important: simple means the process stays in the foreground, forking means it daemonizes itself, notify means it signals readiness through sd_notify, and oneshot means it runs once and exits. Getting the type wrong causes systemd to think the service has failed when it is running correctly.
The [Install] section and enabling. The WantedBy=multi-user.target line is what makes the service start at boot. The systemctl enable command creates the symlink that links the unit into the target’s wants directory. Without the [Install] section, the service can be started manually but not enabled.
The SysV init script. The traditional form is a shell script in /etc/init.d/ that accepts start, stop, restart, reload, and status arguments. The script does the work of starting and stopping the daemon, and the runlevel symlinks in /etc/rc*.d/ determine when it starts.
Why the unit file is preferred. The unit file is declarative, so systemd knows more about the service — its dependencies, its restart policy, its user — and can manage it more intelligently. The init script is imperative, so the script does the work and systemd is limited to running it and reading its exit code.
Why the unit file location matters. Units in /usr/lib/systemd/system/ are shipped by packages and should not be edited. Units in /etc/systemd/system/ are the administrator’s, and they override the package’s units. The systemctl edit command creates an override file that adds or changes directives without editing the original, which is the correct way to customize a packaged unit.
Dependencies and ordering
Services depend on other services, and the dependencies determine the order in which they start. The dependency system is what ensures that the network is up before sshd starts and that the logging service is running before anything logs.
The dependency types. systemd distinguishes between requirements and ordering.
| Directive | Meaning |
|---|---|
Requires= | Hard dependency; if the required unit fails, this one does too |
Wants= | Soft dependency; if the required unit fails, this one still runs |
After= | Ordering; this unit starts after the named unit |
Before= | Ordering; this unit starts before the named unit |
Conflicts= | Mutual exclusion |
Why requirements and ordering are separate. A service can require another without caring about the order, or care about the order without a requirement. After=network.target means “start after the network,” but it does not require the network to be up. Requires=network.target means “fail if the network fails.” The two are independent, and the combination is what the administrator specifies.
Why the distinction matters. A service that uses Requires= unnecessarily can fail because of an unrelated service’s failure. A service that uses only After= will not start until the other unit is started, but will start anyway if the other unit fails. The choice depends on whether the dependency is essential.
The target units. A target is a grouping of units that represents a state of the system — multi-user.target is the normal multi-user state, graphical.target adds the GUI, rescue.target is the single-user rescue mode. The target is analogous to a runlevel, and the services are grouped under it. The systemctl get-default command shows the default target, and systemctl isolate switches to another.
Why the ordering is a partial order, not a sequence. systemd starts services in parallel where the ordering permits. The After= and Before= directives establish a partial order, and systemd starts as many services as the ordering allows. This is what makes the boot parallel and fast. The order is deterministic where it matters and parallel where it does not.
Why a circular dependency is an error. If A is After=B and B is After=A, the ordering is impossible, and systemd reports an error. The cycle is a configuration mistake, and the fix is to break the cycle by removing one of the ordering directives or by restructuring the services.
Why the dependency graph matters for diagnosis. When a service fails to start, the reason is often a dependency that did not start. The systemctl list-dependencies command shows the graph, and systemctl status shows the state of the dependencies. The failure is at the root of the graph, and the dependent service fails because its prerequisite is missing.
Why the dependency model replaced the runlevel ordering. SysV ordering was determined by the numeric prefix of the symlinks —
S20networkingbeforeS50sshd. The numbering is a convention, not a declaration, and the actual dependencies are implicit. systemd’s directives declare the dependencies explicitly, which makes the ordering correct by construction rather than by convention.
Why services fail
A service can fail for many reasons, and the failure is diagnosed by looking at the service’s state, its logs, and its dependencies.
The program is missing. The package was removed, or the path in the unit file is wrong. The failure is immediate, and the log shows “No such file or directory.”
The configuration is invalid. A syntax error in the configuration file causes the service to fail at startup. The log shows the error and the line. This is common after a configuration change that was not validated.
A port is already in use. Another process is listening on the port the service wants. The failure is “Address already in use,” and the diagnosis is to find the other process with ss -tlnp.
A permission is missing. The service runs as a non-root user and cannot read a file it needs, or bind a port below 1024. The log shows “Permission denied.”
A dependency failed. The service starts before the dependency is ready, or the dependency failed. The systemctl status shows the dependency’s state, and the fix is to correct the dependency or the ordering.
The service crashed after starting. The process started, ran for a while, and exited. The Restart= directive determines whether systemd restarts it. The log shows the crash, and the journalctl -u service command shows the output.
The service is running but not responding. The process is alive but not accepting connections. This is the hardest to diagnose, because the service does not report the failure. The diagnosis involves checking the listening socket, the service’s internal state, and the resource usage.
Why the log is the first place to look. Almost every failure leaves a message in the log. The journalctl -u service command shows the service’s output, and the -e flag jumps to the end. The message usually names the cause — a missing file, a syntax error, a port conflict, a permission.
Why the restart policy matters. A service that crashes occasionally and is restarted automatically is resilient. A service that crashes repeatedly and is restarted is a problem, because the restart loop consumes resources and hides the failure. The Restart= and RestartSec= directives control the policy, and the systemctl status shows the restart count.
Why the failure should be understood, not just worked around. Restarting a service that failed is a temporary fix. The failure has a cause, and the cause should be found in the log and fixed in the configuration. The restart is the first step; the diagnosis is the work.
Complete Example Session
# ============================================
# PART 1: LIST SERVICES
# ============================================
systemctl list-units --type=service
# UNIT LOAD ACTIVE SUB DESCRIPTION
# ssh.service loaded active running OpenBSD Secure Shell server
# nginx.service loaded active running A high performance web server
# cron.service loaded active running Regular background program
# ...
# ============================================
# PART 2: CHECK A SERVICE
# ============================================
systemctl status ssh
# ● ssh.service - OpenBSD Secure Shell server
# Loaded: loaded (/lib/systemd/system/ssh.service; enabled; preset: enabled)
# Active: active (running) since Mon 2026-03-15 10:00:00 UTC; 2h ago
# Docs: man:sshd(8)
# man:sshd_config(5)
# Process: 1234 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)
# Main PID: 1235 (sshd)
# Tasks: 1 (limit: 12345)
# Memory: 5.2M
# CPU: 123ms
# CGroup: /system.slice/ssh.service
# └─1235 "sshd: /usr/sbin/sshd -D [listener]"
# ============================================
# PART 3: VIEW THE UNIT FILE
# ============================================
systemctl cat ssh
# Shows the unit file and any overrides
systemctl show ssh
# Shows all the unit's properties
# ============================================
# PART 4: READ THE SERVICE LOG
# ============================================
journalctl -u ssh -n 20
# Shows the last 20 log entries
journalctl -u ssh -f
# Follows the log
journalctl -u ssh --since "1 hour ago"
# Shows entries from the last hour
# ============================================
# PART 5: DEPENDENCIES
# ============================================
systemctl list-dependencies ssh
# ssh.service
# ├─system.slice
# └─network.target
# ├─...
# ============================================
# PART 6: LISTENING PORTS
# ============================================
ss -tlnp | grep :22
# LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=1235,fd=3))
# ============================================
# PART 7: WHY A SERVICE FAILED
# ============================================
systemctl status nginx
# ● nginx.service - A high performance web server
# Loaded: loaded (/lib/systemd/system/nginx.service; enabled)
# Active: failed (Result: exit-code) since Mon 2026-03-15 12:00:00 UTC
# Process: 5678 ExecStart=/usr/sbin/nginx (code=exited, status=1/FAILURE)
journalctl -u nginx -n 10
# nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
ss -tlnp | grep :80
# LISTEN 0 511 0.0.0.0:80 0.0.0.0:* users:(("apache2",pid=9999,fd=4))
# The port is taken by apache2.
# ============================================
# PART 8: THE UNIT FILE
# ============================================
cat /lib/systemd/system/nginx.service
# [Unit]
# Description=A high performance web server
# After=network.target
#
# [Service]
# Type=forking
# ExecStartPre=/usr/sbin/nginx -t
# ExecStart=/usr/sbin/nginx
# ExecReload=/usr/sbin/nginx -s reload
# ExecStop=/sbin/start-stop-daemon --stop --quiet --pidfile /run/nginx.pid
# Restart=on-failure
#
# [Install]
# WantedBy=multi-user.target
# ============================================
# PART 9: OVERRIDE A UNIT
# ============================================
systemctl edit nginx
# Creates /etc/systemd/system/nginx.service.d/override.conf
# Inside:
# [Service]
# RestartSec=10s
# The override adds the directive without editing the original.
# ============================================
# PART 10: WHAT NOT TO DO
# ============================================
# Don't edit the package's unit file directly
# Use systemctl edit.
# Don't start a service outside the init system
# nohup and setsid are for one-off jobs.
# Don't ignore the log
# The failure reason is in journalctl.
# Don't restart a failing service without checking the cause
# The restart loop hides the problem.
# Don't confuse a daemon with a service
# A daemon outside the init system is not supervised.The ten parts cover listing, checking, reading the unit, the log, dependencies, ports, failure diagnosis, the unit file, overrides, and the anti-patterns.
Quick Reference
Service Concepts
| Concept | Meaning |
|---|---|
| Service | Long-running background program |
| Daemon | Background process without a terminal |
| Init system | Manages services (PID 1) |
| Unit | systemd’s service definition |
| Target | A group of units representing a state |
| Dependency | A requirement or ordering between units |
Service Lifecycle
| State | Meaning |
|---|---|
inactive | Not running |
active (running) | Running |
active (exited) | Ran and exited successfully (oneshot) |
failed | Exited with an error |
activating | Starting |
deactivating | Stopping |
systemd Unit Sections
| Section | Purpose |
|---|---|
[Unit] | Metadata and dependencies |
[Service] | How to run the program |
[Install] | What happens when enabled |
Key Directives
| Directive | Purpose |
|---|---|
ExecStart | The command to run |
ExecReload | Reload configuration |
Restart | Restart policy |
User / Group | Run as user |
Type | Startup detection |
Wants / Requires | Dependencies |
After / Before | Ordering |
WantedBy | Enable target |
Unit File Locations
| Location | Purpose |
|---|---|
/usr/lib/systemd/system/ | Package-provided |
/etc/systemd/system/ | Administrator-provided |
/etc/systemd/system/*.d/ | Overrides |
/run/systemd/system/ | Runtime |
Why Services Fail
| Cause | Diagnosis |
|---|---|
| Missing program | journalctl -u service |
| Invalid config | Log shows syntax error |
| Port in use | ss -tlnp | grep :port |
| Permission denied | Log shows the file |
| Dependency failed | systemctl status |
| Crash after start | Log + restart policy |
Best Practices
✅ Do This:
# Check the service status before diagnosing
systemctl status ssh # ✅
# Read the log for the failure reason
journalctl -u nginx -n 50 # ✅
# Check the dependencies
systemctl list-dependencies ssh # ✅
# Use systemctl edit for overrides
systemctl edit nginx # ✅
# Check the listening port
ss -tlnp | grep :80 # ✅
# Validate config before restarting
sudo nginx -t # ✅
# Use the journal for service logs
journalctl -u myservice -f # ✅❌ Don’t Do This:
# Don't edit the package's unit file directly
vim /lib/systemd/system/nginx.service # use systemctl edit # ⚠️
# Don't start a service outside the init system
nohup ./myservice & # not supervised # ⚠️
# Don't restart without checking the cause
systemctl restart nginx # if it keeps failing, find out why # ⚠️
# Don't ignore a failed service
# The capability it provides is broken # ⚠️
# Don't assume the service is running because the process exists
# The process may be a manual start, not the service # ⚠️
# Don't confuse the unit state with the process state
# systemd tracks the unit; a stray process is not the unit # ⚠️Common Pitfalls
| Pitfall | Problem | Solution |
|---|---|---|
| Editing package unit | Overwritten on upgrade | systemctl edit |
| Service not enabled | Not started at boot | systemctl enable |
| Port conflict | Address in use | Find the other process |
Wrong Type | systemd thinks it failed | Match the daemonization |
| Dependency cycle | Ordering impossible | Break the cycle |
| Log not checked | Cause unknown | journalctl -u |
| Manual daemon start | Not supervised | Use the init system |
| Restart loop | Hides the problem | Diagnose the failure |
Real-World Examples
1. Check a service
systemctl status ssh2. List services
systemctl list-units --type=service3. Read the log
journalctl -u nginx -n 504. Follow the log
journalctl -u myservice -f5. View the unit
systemctl cat ssh6. Override a unit
systemctl edit nginx7. Dependencies
systemctl list-dependencies ssh8. Check the port
ss -tlnp | grep :809. Enable a service
systemctl enable nginx10. Diagnose a failure
systemctl status nginx && journalctl -u nginx -n 20Visual: The Init System
┌──────────────────────────────────────────────────────────┐
│ KERNEL │
│ │ │
│ │ starts PID 1 │
│ ▼ │
│ INIT SYSTEM (systemd) │
│ │ │
│ ├── Reads unit files │
│ ├── Builds the dependency graph │
│ ├── Starts services in the correct order │
│ ├── Supervises services │
│ ├── Restarts failed services │
│ └── Stops services at shutdown │
│ │ │
│ ├── sshd.service │
│ ├── nginx.service │
│ ├── cron.service │
│ ├── NetworkManager.service │
│ └── systemd-journald.service │
│ │
│ The init system is the supervisor of the system. │
│ │
└──────────────────────────────────────────────────────────┘Visual: A systemd Unit File
┌──────────────────────────────────────────────────────────┐
│ [Unit] │
│ Description=OpenSSH server daemon │
│ After=network.target │
│ Wants=sshd-keygen.target │
│ │
│ [Service] │
│ Type=notify │
│ ExecStart=/usr/sbin/sshd -D │
│ ExecReload=/bin/kill -HUP $MAINPID │
│ Restart=on-failure │
│ RestartSec=42s │
│ │
│ [Install] │
│ WantedBy=multi-user.target │
│ │
│ [Unit] → metadata and dependencies │
│ [Service] → how to run the program │
│ [Install] → what happens when enabled │
│ │
└──────────────────────────────────────────────────────────┘Visual: Dependency Types
┌──────────────────────────────────────────────────────────┐
│ Requires=network.target │
│ Hard dependency. │
│ If the network fails, this unit fails. │
│ │
│ Wants=sshd-keygen.target │
│ Soft dependency. │
│ If the keygen fails, this unit still starts. │
│ │
│ After=network.target │
│ Ordering only. │
│ Start after the network, but do not require it. │
│ │
│ Before=other.service │
│ Ordering only. │
│ Start before the other unit. │
│ │
│ Requires + After is the common combination. │
│ │
└──────────────────────────────────────────────────────────┘Visual: Service Lifecycle
┌──────────────────────────────────────────────────────────┐
│ BOOT │
│ │ │
│ ▼ │
│ systemd starts the service │
│ │ │
│ ▼ │
│ ACTIVE (running) │
│ │ │
│ ├── reload ──► re-read config │
│ ├── restart ──► stop then start │
│ ├── crash ──► Restart= policy decides │
│ └── stop ──► INACTIVE │
│ │
│ FAILED │
│ The service exited with an error. │
│ The log shows the reason. │
│ The Restart= policy may restart it. │
│ │
└──────────────────────────────────────────────────────────┘Visual: Diagnosing a Service Failure
┌──────────────────────────────────────────────────────────┐
│ systemctl status nginx │
│ └── shows Active: failed │
│ │
│ journalctl -u nginx -n 20 │
│ └── shows the error message │
│ │
│ Common causes: │
│ ├── "Address already in use" │
│ │ └── ss -tlnp | grep :80 │
│ │ │
│ ├── "Permission denied" │
│ │ └── check the user and the file │
│ │ │
│ ├── "No such file or directory" │
│ │ └── check ExecStart path │
│ │ │
│ └── "syntax error" │
│ └── validate the config │
│ │
│ The log is the first place to look. │
│ │
└──────────────────────────────────────────────────────────┘Visual: systemd vs SysV
┌──────────────────────────────────────────────────────────┐
│ SYSV INIT │
│ - Shell scripts in /etc/init.d/ │
│ - Runlevel symlinks in /etc/rc*.d/ │
│ - Ordering by numeric prefix │
│ - Sequential startup │
│ - No restart on failure │
│ │
├──────────────────────────────────────────────────────────┤
│ SYSTEMD │
│ - Unit files in /etc/systemd/system/ │
│ - Targets and dependencies │
│ - Parallel startup │
│ - Restart on failure │
│ - Journal for logs │
│ - One command: systemctl │
│ │
│ The concepts are the same; the mechanism is different. │
│ │
└──────────────────────────────────────────────────────────┘Summary
| Concept | Meaning |
|---|---|
| Service | Long-running background program |
| Daemon | Process without a terminal |
| Init system | PID 1, manages services |
| systemd | The modern init system |
| Unit file | Service definition |
| Target | Group of units |
| Dependency | Requires / Wants |
| Ordering | After / Before |
| Journal | Centralized service logs |
| Lifecycle State | Meaning |
|---|---|
inactive | Not running |
active (running) | Running |
active (exited) | Ran and exited (oneshot) |
failed | Exited with error |
activating | Starting |
deactivating | Stopping |
Key takeaways:
- A system service is a long-running background program managed by the init system — it provides a capability that the system needs continuously
- A daemon is a process without a terminal; a service is a daemon the init system supervises — the difference is whether the init system is aware of it
- Almost every system capability is a service — networking, logging, time, remote access, scheduling, and more
- systemd is the modern init system — it starts services in parallel, tracks dependencies explicitly, restarts failed services, and provides
journalctlfor logs - A unit file declares the service — the
[Unit]section for metadata and dependencies, the[Service]section for how to run, the[Install]section for enabling Requiresis a hard dependency andWantsis a soft one —AfterandBeforeare ordering only, and the two are independent- Targets group units by system state —
multi-user.targetis the normal multi-user state, and the runlevel concept is expressed as targets - The
Typedirective matters —simple,forking,notify, andoneshottell systemd how to detect that the service has started - Services fail for predictable reasons — a missing program, an invalid configuration, a port conflict, a permission problem, a failed dependency — and the log is the first place to look
- The log is the diagnostic —
journalctl -u serviceshows the service’s output, and the failure reason is almost always there
Remember: A system service is a program the system runs continuously and the init system supervises. The init system is systemd on almost every modern distribution, and the unit file is how a service is defined. Dependencies and ordering are declared, the restart policy determines resilience, and the journal collects the logs. Knowing what a service is and how it is defined is the foundation for managing them, which is the next chapter.
Stop using slow, ad-bloated tool sites! 🤮
🔎 Search “KandZ Tools” on Google to use many professional utilities for free.
KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)
⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free
🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!