systemd tidak mengelola program secara langsung — program hanyalah berkas yang diam di disk. Objek yang systemd kenal bernama unit: sumber daya yang dinamai, dideklarasikan, dan dilacak tersendiri — dari service, socket, hingga titik sinkronisasi boot. Setiap unit didefinisikan dalam satu unit file — berkas teks berformat sederhana yang bisa kita baca, salin, dan ubah. Chapter ini memetakan jenis-jenis unit, lokasi berkasnya di filesystem, dan anatomi isinya.

Jenis Unit dan Tugasnya Masing-masing #

Nama unit diakhiri ekstensi yang menyatakan jenisnya: backup.service adalah service, backup.timer adalah timer — dan systemd membaca ekstensi itu untuk menentukan directive mana yang sah dalam berkasnya. Jenis yang paling sering kita temui:

JenisTugasContoh
.servicemenjalankan program: daemon panjang atau tugas sekali jalandbus.service
.socketmenahan socket, lalu menyalakan service saat koneksi datangdbus.socket
.timermenjadwalkan aktivasi unit lain via kalender atau selang waktuapt-daily.timer
.targettitik sinkronisasi yang mengelompokkan unit lainmulti-user.target
.mountmengaitkan filesystem ke satu titik mounthome.mount
.pathmengawasi berkas/folder dan memicu service saat keadaannya berubahsystemd-ask-password-console.path
.devicemewakili perangkat kernel yang dikenali udevdev-sda1.device
.slicemengelompokkan proses dalam hierarki cgroupuser.slice

Karena unit dikirim sebagai berkas biasa, kita bisa menghitung sendiri jenis apa yang terpasang:

bash
for t in service socket timer target mount path device slice; do
  printf '%-8s %s\n' "$t" "$(ls /lib/systemd/system/ | grep -c "\.$t$")"
done

Output yang Dihasilkan:

text
service  119
socket   15
timer    5
target   69
mount    9
path     2
device   0
slice    3

Mari kita telaah hasilnya:

  1. service paling banyak (119): wajar, karena menjalankan program adalah pekerjaan utama init system.
  2. target kedua terbanyak (69): setiap target adalah satu titik sinkronisasi boot.
  3. device bernilai 0: unit device tidak dikirim sebagai berkas — systemd menciptakannya saat runtime dari peristiwa perangkat kernel yang dilaporkan udev.

Tiga Lokasi Berkas dengan Urutan Prioritas #

systemd mencari unit file di tiga lokasi; urutan berikut menentukan pemenang bila nama yang sama muncul lebih dari sekali:

LokasiPemilikIsi tipikal
/etc/systemd/systemadministratorunit buatan sendiri dan hasil kustomisasi
/run/systemd/systemruntimeunit sementara saat sistem berjalan
/lib/systemd/systempaketunit yang datang bersama paket

Aturan mainnya: /etc menimpa /run, dan /run menimpa /lib. Administrator bisa mengganti perilaku unit milik paket tanpa menyentuh berkas aslinya, dan pembaruan paket tidak pernah menimpa kustomisasi di /etc. Di Debian, /lib adalah symlink ke /usr/lib/systemd/system. Isi milik administrator di sistem ini:

bash
ls /etc/systemd/system/

Output yang Dihasilkan:

text
getty.target.wants
multi-user.target.wants
sysinit.target.wants
timers.target.wants

Empat entri berakhiran .wants itu bukan unit, melainkan folder penampung symlink — mekanisme “siapa yang ditarik target” yang kita praktikkan di Chapter Managing Services .

Anatomi Unit File: Section dan Key=Value #

Unit file memakai format mirip INI: berkas terbagi menjadi section dalam kurung siku, dan tiap section berisi pasangan Key=Value; tanda # memulai komentar, dan nama key peka huruf besar-kecil. Daftar section, key, dan nilainya yang sah dirinci lengkap di systemd.unit(5) . Sebagai contoh nyata, mari kita bedah unit milik D-Bus — bus pesan antar-aplikasi yang menjadi fondasi desktop dan banyak service sistem:

bash
cat /lib/systemd/system/dbus.service

Output yang Dihasilkan:

text
[Unit]
Description=D-Bus System Message Bus
Documentation=man:dbus-daemon(1)
Requires=dbus.socket

[Service]
Type=notify
NotifyAccess=main
ExecStart=/usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
ExecReload=/usr/bin/dbus-send --print-reply --system --type=method_call --dest=org.freedesktop.DBus / org.freedesktop.DBus.ReloadConfig
OOMScoreAdjust=-900
User=messagebus
Group=messagebus
AmbientCapabilities=CAP_AUDIT_WRITE

Mari kita baca isinya baris per baris:

  1. Baris 1-4 ([Unit] sampai Requires=): section [Unit] menjelaskan unit dan relasinya dengan unit lain: Description adalah nama yang tampil di systemctl status, Documentation menautkan manual, dan Requires=dbus.socket menyatakan service ini tidak boleh hidup tanpa socket-nya — materi Chapter Service Dependencies .
  2. Baris 7 (Type=notify): dbus-daemon memberi tahu systemd sendiri setelah siap melayani, sehingga systemd tahu tepat kapan unit ini aktif.
  3. Baris 9 (ExecStart=...): perintah yang dijalankan saat service menyala — dbus-daemon berjalan di latar depan karena urusan latar belakang sudah diurus systemd lewat cgroups.
  4. Baris 10 (ExecReload=...): perintah khusus untuk memuat ulang konfigurasi tanpa mematikan service — inilah yang dipanggil systemctl reload.
  5. Baris 12-14 (User=, Group=, AmbientCapabilities=): proses diturunkan ke user messagebus dengan satu kapabilitas tambahan — contoh kecil prinsip hak serendah mungkin.

Berkas ini sengaja tanpa section [Install]; unit semacam ini disebut static — tidak bisa diaktifkan untuk boot, hanya ditarik oleh unit lain.

Dari Berkas di Disk ke Unit di Memori #

Satu nama unit menunjuk tepat satu definisi aktif — pemenang dari kompetisi tiga lokasi tadi. systemd membacanya saat unit dimuat, baik melalui daemon-reload maupun saat unit pertama kali dibutuhkan. Tiga istilah yang sering tertukar perlu dipisahkan di sini: berkas di disk dimuat (loaded) ke memori, unit yang sedang berjalan disebut aktif, dan unit yang dipersiapkan untuk boot berikutnya disebut enabled — tiga kata kerja yang menjadi peta jalan Chapter Managing Services .

Berkas-berkas ini diam sampai ada yang mengelolanya: satu perintah serba bisa bernama systemctl — topik dua chapter berikutnya.