Linux İşletim Sistemlerinde Servis Yönetimi

Introduction

Service management is one of the most fundamental responsibilities of a Linux system administrator. Every running daemon — from your SSH server to your web server — is a service that must be started, stopped, enabled at boot, and monitored. This post covers the three main service management systems found across Linux distributions: SysVinit, systemd, and Upstart.

What is a service manager?

When the Linux kernel finishes loading, it hands off control to a single process with PID 1 — the init system. This process is responsible for starting all other services and keeping them running. You can verify which init system is in use:

bash# Check which binary /sbin/init points to
readlink -f /sbin/init
/usr/lib/systemd/systemd

# View it as a running process
ps -p 1
  PID TTY          TIME CMD
    1 ?        00:00:03 systemd

You can also visualise the entire process tree, tracing every process back to PID 1:

bashpstree

---

SysVinit

SysVinit (System V init) is the traditional init system inherited from Unix System V. It is still found on older distributions and in embedded Linux systems. The main binary is /sbin/init, and its primary configuration file is /etc/inittab.

Runlevels

SysVinit organises system states into runlevels — numbered 0 through 6, each representing a predefined system state:

Runlevel	Meaning
0	System shutdown
1 / s / single	Single-user maintenance mode, no networking
2, 3, 4	Multi-user mode (console or network); runlevel 3 most common
5	Multi-user graphical mode (runlevel 3 + GUI login)
6	System restart (reboot)

To change the current runlevel, use telinit:

bash# Switch to maintenance mode
telinit 1

# Reboot the system
telinit 6

# Display previous and current runlevel
runlevel
N 3

/etc/inittab

The /etc/inittab file defines the default runlevel and the scripts to execute. Each entry follows the format:

formatid:runlevels:action:process

The default runlevel must never be set to 0 or 6 — doing so will cause the system to shut down or reboot immediately after every boot.

After modifying /etc/inittab, reload the configuration without rebooting:

bashtelinit q

Service scripts live in /etc/init.d/. Symbolic links in /etc/rcN.d/ control which services start or stop for each runlevel. A link prefixed S starts the service; K kills it. The number after the prefix sets the execution order.

example# Inside /etc/rc3.d/
S23ntp -> /etc/init.d/ntp    # Start ntp at order 23
K90network -> /etc/init.d/network  # Stop network at order 90

---

systemd

systemd is the dominant init system in modern Linux. It replaces the sequential shell-script approach of SysVinit with parallel, dependency-driven service startup, and provides a unified interface for logging, device management, and power events.

Units and unit files

In systemd, every managed resource is a unit. Units have a name, a type, and a configuration file. The main unit types are:

• service — a daemon or process
• target — a grouping of units (like a runlevel)
• socket — socket-activated service
• timer — scheduled task (cron replacement)
• automount — filesystem mount triggered on access

Unit files are searched in order:

paths/etc/systemd/system/        # Admin overrides (highest priority)
/run/systemd/system/        # Runtime units
/usr/lib/systemd/system/    # Vendor-provided units

systemctl commands

bash# Start / stop / restart / reload
systemctl start   apparmor.service
systemctl stop    apparmor.service
systemctl restart apparmor.service
systemctl reload  sshd.service        # graceful reload, no disconnect

# Status checks
systemctl status     apparmor.service
systemctl is-active  sshd.service     # prints: active / inactive
systemctl is-enabled apparmor.service # prints: enabled / disabled

# Enable / disable at boot
systemctl enable  apparmor.service
systemctl disable apparmor.service

# List all units / unit files
systemctl list-units
systemctl list-units --type=service
systemctl list-unit-files

# Inspect a unit file
systemctl cat sshd.service

# After editing unit files
systemctl daemon-reload

Boot targets

systemd targets are the equivalent of SysV runlevels. The most important ones:

Target	SysV equivalent	Description
poweroff.target	0	Shut down the system
rescue.target	1	Single-user rescue shell
multi-user.target	3	Multi-user, no GUI
graphical.target	5	Multi-user with GUI
reboot.target	6	Reboot the system
emergency.target	—	Minimal emergency shell

bash# View and set the default boot target
systemctl get-default
systemctl set-default multi-user.target

# Switch targets without rebooting
systemctl isolate multi-user.target
systemctl isolate emergency

# Power management
systemctl reboot
systemctl poweroff
systemctl suspend
systemctl hibernate

# Forced reboot (skips shutdown hooks)
systemctl reboot --force
# Immediate hardware reset (double --force)
systemctl reboot --force --force

Scheduled shutdowns with wall messages use the traditional shutdown command:

bashsudo shutdown -r 02:00              # reboot at 02:00
sudo shutdown -r +15                # reboot in 15 minutes
sudo shutdown +15 'Going offline'   # shutdown with message
sudo shutdown -c                    # cancel a pending shutdown

---

Upstart

Upstart was developed by Canonical as an event-driven replacement for SysVinit, used in Ubuntu from 6.10 to 14.10 before Ubuntu switched to systemd. Job configuration files live in /etc/init/.

bash# List jobs and their states
initctl list

# Start / stop a job
start nginx
stop nginx

---

Comparison table

Feature	SysVinit	systemd	Upstart
Config location	/etc/inittab	Unit files	/etc/init/
Service scripts	/etc/init.d/	Built-in	Job files
Startup model	Sequential	Parallel	Event-driven
Logging	syslog	journald	syslog
Main command	telinit	systemctl	initctl
State concept	Runlevels	Targets	Events

Conclusion

Understanding all three init systems gives you the full picture of how Linux service management evolved. In practice, systemctl is what you'll use day-to-day on any modern system — but knowing the SysVinit model helps you reason about what systemd is doing under the hood. The /etc/rc*.d/ symlink convention, runlevels, and /etc/inittab are part of the LPIC and Linux+ certification exams, so they're worth keeping in memory.