Belajar Linux - Pengenalan dan Penjelasan Systemd & Managing Services

#Pendahuluan

Setelah di episode 13 sebelumnya kita membahas manajemen proses — PID, state, sinyal, background jobs, sampai nohup dan tmux — ada pertanyaan yang sengaja kita gantung: bagaimana membuat sebuah proses bertahan hidup secara resmi? Kalian sudah tahu nohup node server.js & bisa membuat aplikasi tetap berjalan setelah terminal ditutup, tapi siapa yang menjaganya jika aplikasi itu crash, atau memastikannya hidup lagi setelah server reboot? Jawabannya adalah systemd.

Systemd adalah init system yang menjadi proses nomor 1 (PID 1) di hampir semua distro modern — ia adalah proses pertama yang dijalankan kernel saat boot, dan proses terakhir yang "meninggal" saat shutdown. Pada episode kali ini kita akan membedah peran systemd sebagai "manajer seluruh proses", mempraktikkan pengelolaan service dengan systemctl, membaca log terpusat dengan journalctl, dan menulis file service unit sendiri untuk aplikasi kalian. Mari kita mulai.

#Pembahasan Utama

#Mengapa Systemd Menjadi PID 1?

Sebelum systemd, Linux menggunakan SysVinit: sebuah sistem berbasis runlevel dan script shell yang menjalankan service satu per satu secara berurutan. Setiap service adalah script yang panjang, tidak ada mekanisme ketergantungan paralel yang baik, dan tidak ada cara terpusat untuk melihat status semua service. Menyalakan server dengan 30 service berarti menunggu 30 script dieksekusi hampir berurutan — lambat dan rapuh. Kemudian muncullah Upstart (event-based, dari Ubuntu) sebagai perbaikan parsial, lalu systemd yang menyelesaikan semuanya.

Systemd mengubah paradigma dari "urutan script" menjadi target dan unit. Setiap service direpresentasikan oleh file unit dengan format deklaratif (bukan script imperatif), service bisa dijalankan secara paralel, ketergantungan dinyatakan secara eksplisit, dan seluruh state service bisa dipantau terpusat. Inilah mengapa sistem modern boot jauh lebih cepat dan lebih mudah dikelola.

Note

Systemd bukan tanpa kritik — sebagian komunitas menganggapnya terlalu besar karena mengelola banyak hal (logging, timer, network, dll) di luar peran init semula. Namun faktanya, systemd telah menjadi standar de facto di distro mainstream (Debian, Ubuntu, RHEL, Fedora, Arch). Untuk karier DevOps, memahami systemd adalah keterampilan yang tidak bisa ditawar.

Bayangkan systemd sebagai manajer hotel. Sebelumnya (SysVinit), setiap tamu (service) diantar manual satu per satu oleh bellhop — urut dan lambat. Systemd adalah resepsionis digital: ia tahu siapa yang harus datang lebih dulu (ketergantungan), siapa yang bisa datang bersamaan (paralel), dan mencatat semua aktivitas tamu di satu buku log. Saat seorang tamu pingsan di lobi, resepsionis menanganinya sesuai aturan — menyalakannya kembali atau memberi tahu manajer.

#Mengelola Service dengan `systemctl`

Kata kunci "unit" di systemd mencakup service, socket, timer, mount, dan lainnya. Unit yang paling sering dikelola adalah service. Perintah pengelolanya adalah systemctl. Berikut siklus hidup lengkap:

Siklus hidup service dengan systemctl

# Mulai service sekarang juga
sudo systemctl start nginx
 
# Hentikan service
sudo systemctl stop nginx
 
# Mulai ulang service (stop lalu start)
sudo systemctl restart nginx
 
# Muat ulang konfigurasi tanpa memutus koneksi
sudo systemctl reload nginx
 
# Aktifkan saat boot (enable) / matikan (disable)
sudo systemctl enable nginx
sudo systemctl disable nginx
 
# Tampilkan status lengkap: running/tidak, sejak kapan, PID, dan log terakhir
systemctl status nginx

start/stop/restart untuk sekarang, enable/disable untuk saat boot

Tip

Bedakan restart dan reload: restart menghentikan lalu menjalankan ulang proses (koneksi terputus sejenak), sedangkan reload mengirim sinyal untuk memuat ulang konfigurasi tanpa downtime. Untuk Nginx, Apache, dan SSH, reload adalah operasi harian yang aman; restart hanya diperlukan saat benar-benar mengubah perilaku dasar proses. Kebiasaan ini akan menjaga availability service di produksi.

Perintah systemctl status adalah jendela pertama setiap troubleshooting — ia menampilkan apakah service active atau failed, PID prosesnya, penggunaan resource, dan beberapa baris log terakhir. Kombinasi systemctl status nginx + journalctl akan menjadi rutinitas kalian setiap kali service bermasalah.

Ada satu detail yang sering terlupakan: setelah mengedit file unit service, kalian wajib memberi tahu systemd agar memuat ulang definisi unit dengan systemctl daemon-reload. Tanpa itu, perubahan kalian diabaikan.

Reload definisi unit setelah mengedit file

sudo systemctl daemon-reload
sudo systemctl restart myapp

Wajib setelah setiap perubahan pada file .service

Selain mengelola service satu per satu, kalian juga perlu melihat gambaran seluruh sistem: service mana yang berjalan, dan mana yang gagal. systemctl list-units adalah dashboard-nya:

Menampilkan daftar unit service

# Semua unit yang sedang aktif
systemctl list-units --type=service
 
# Hanya service yang gagal (langkah pertama troubleshooting server)
systemctl list-units --type=service --state=failed
 
# Cek cepat status dalam bentuk teks (berguna untuk script)
systemctl is-active nginx

list-units untuk daftar, is-active untuk cek cepat dalam script

systemctl is-active nginx mengembalikan active atau inactive, dan keluar dengan exit code yang bisa dipakai logika script — pola yang akan sering kalian jumpai saat menulis script monitoring atau alerting sendiri.

#Membaca Log dengan `journalctl`

Salah satu keunggulan besar systemd adalah logging terpusat: semua service menulis log ke journal, dan kalian membacanya dengan journalctl — tanpa perlu membuka file log terpisah di /var/log. Ini mengubah cara admin mencari masalah: dari "cari file log yang mana?" menjadi "log service ini di mana saja".

Kombinasi journalctl yang paling sering dipakai

# Semua log untuk satu service
sudo journalctl -u nginx
 
# Ikuti log secara live (seperti tail -f)
sudo journalctl -u nginx -f
 
# 50 baris log terakhir
sudo journalctl -u nginx -n 50
 
# Log sejak satu jam yang lalu
sudo journalctl -u nginx --since "1 hour ago"
 
# Log pada rentang waktu spesifik
sudo journalctl -u nginx --since "2026-08-01 09:00" --until "2026-08-01 12:00"

Filter per service, ikuti live, batasi jumlah, filter waktu

Contoh output journalctl

Aug 01 09:15:22 webserver systemd[1]: Starting nginx...
Aug 01 09:15:22 webserver nginx[3456]: nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
Aug 01 09:15:22 webserver nginx[3456]: nginx: configuration file /etc/nginx/nginx.conf test is successful
Aug 01 09:15:22 webserver systemd[1]: Started nginx.
Aug 01 09:17:03 webserver nginx[3456]: 192.168.1.10 - - [01/Aug/2026:09:17:03] "GET /" 200 612
Aug 01 09:18:44 webserver nginx[3456]: [error] upstream prematurely closed connection

Setiap baris punya timestamp & source; cari kata kunci dengan grep

Kombinasi journalctl -u nginx --since "1 hour ago" adalah refleks pertama saat user melapor "server mulai lambat sejam yang lalu" — kalian langsung melihat apa yang terjadi pada service di jam itu. journalctl juga bisa difilter dengan -p untuk level prioritas (err, warning, dll) dan grep untuk pola tertentu.

Tip

Log di journal itu persisten? Tergantung konfigurasi — secara default journal bisa hanya disimpan di memori hingga reboot. Untuk server produksi, aktifkan persistensi dengan sudo mkdir -p /var/log/journal lalu sudo systemd-tmpfiles --create --prefix /var/log/journal. Ini memastikan riwayat log tetap ada untuk investigasi, dan logrotate tetap berjalan agar disk tidak penuh.

#Menulis Service Unit File Sendiri

Inilah bagian paling berharga di episode ini: membuat aplikasi kalian menjadi service resmi yang di-manage systemd. Bayangkan kalian punya aplikasi myapp — sebuah binary atau script di /opt/myapp/ — dan ingin systemd menjaganya: mulai saat boot, restart jika crash, dan mencatat lognya.

File unit diletakkan di /etc/systemd/system/myapp.service, dan dibagi menjadi tiga bagian standar:

Bagian	Fungsi
`[Unit]`	Metadata & ketergantungan (setelah apa service ini jalan)
`[Service]`	Cara menjalankan: perintah, user, restart policy
`[Install]`	Kapan diaktifkan saat boot (target)

/etc/systemd/system/myapp.service

[Unit]
Description=My Production Application
After=network.target
 
[Service]
Type=simple
User=myapp
WorkingDirectory=/opt/myapp
ExecStart=/usr/bin/node /opt/myapp/server.js
Restart=on-failure
RestartSec=5
 
[Install]
WantedBy=multi-user.target

Unit lengkap: deklaratif, bukan script

Mari bedah setiap baris penting:

After=network.target — service hanya dijalankan setelah target network tercapai, sehingga aplikasi tidak mulai sebelum jaringan siap.
Type=simple — systemd menganggap proses utama adalah yang dijalankan ExecStart langsung. Ini default yang benar untuk kebanyakan aplikasi modern (Node, Python, Go).
User=myapp — menjalankan service sebagai user non-root. Inilah implementasi least privilege di level service.
Restart=on-failure — systemd akan menyalakan ulang service jika ia keluar dengan status error. Ini adalah "asuransi" utama availability.
RestartSec=5 — jeda 5 detik sebelum mencoba restart (mencegah restart storm).
WantedBy=multi-user.target — di bagian [Install]; menentukan bahwa systemctl enable akan mengaitkan service ke target multi-user (berjalan di boot normal, tanpa GUI).

Perintah untuk mengaktifkan unit baru:

Mengaktifkan dan menjalankan service kustom

sudo systemctl daemon-reload
sudo systemctl enable myapp
sudo systemctl start myapp
systemctl status myapp

Urutan wajib: daemon-reload → enable → start

Important

enable dan start adalah dua hal yang berbeda. enable mengaitkan service ke target boot (bisa dijalankan saat reboot), sedangkan start menjalankannya sekarang. systemctl enable --now myapp melakukan keduanya sekaligus — kombinasi yang sangat direkomendasikan. Banyak pemula hanya start, lalu bingung kenapa service tidak jalan setelah reboot: jawabannya, mereka lupa enable.

Sekarang lihat bagaimana diffs bekerja saat kita menambahkan mekanisme restart yang lebih agresif — misalnya ingin aplikasi selalu dinyalakan ulang apa pun penyebabnya. Perhatikan baris -- yang dihapus dan ++ yang ditambahkan:

/etc/systemd/system/myapp.service (Restart policy)

[Service]
Type=simple
User=myapp
WorkingDirectory=/opt/myapp
ExecStart=/usr/bin/node /opt/myapp/server.js
Restart=on-failure
Restart=always
RestartSec=5

Mengubah on-failure menjadi always: restart apa pun penyebabnya

Setelah perubahan, jangan lupa urutan ritualnya: sudo systemctl daemon-reload lalu sudo systemctl restart myapp.

#Menangani Aplikasi Forking dan Type Lain

Ada satu jebakan klasik yang membuat admin pemula menulis Type=forking padahal tidak perlu. Type=forking digunakan untuk aplikasi yang "mem-fork" dirinya: proses ExecStart memulai dan langsung keluar, sedangkan proses pekerja (daemon) berjalan di latar belakang. Contoh klasiknya adalah script daemon lama dan beberapa aplikasi C/C++ tradisional. Untuk daemon semacam ini, systemd butuh PIDFile= agar tahu proses mana yang harus dilacak:

/etc/systemd/system/mydaemon.service (forking)

[Service]
Type=forking
User=daemon
ExecStart=/usr/local/bin/mydaemon start
ExecStop=/usr/local/bin/mydaemon stop
PIDFile=/run/mydaemon.pid
Restart=on-failure
 
[Install]
WantedBy=multi-user.target

Type=forking wajib disertai PIDFile, jika tidak systemd kehilangan jejak proses

Caution

Jangan gunakan Type=forking hanya karena "terlihat seperti daemon". Sebagian besar aplikasi modern — Node.js, Python, Go, Java — berjalan di foreground, dan jawaban yang benar adalah Type=simple. Salah memilih Type menghasilkan gejala aneh: systemctl status menampilkan "active (running)" padahal proses sudah mati, atau sebaliknya. Mulailah dengan simple, dan beralih ke forking hanya jika dokumentasi aplikasi menyebutnya demikian.

Ada juga Type=oneshot untuk service yang menjalankan satu tugas lalu selesai (seperti script inisialisasi), dan Type=notify untuk aplikasi yang memberi tahu systemd melalui socket sd_notify bahwa mereka sudah siap (dipakai service besar seperti database). Ketika nanti kalian mempelajari systemd timers di episode 22, Type=oneshot akan jadi sahabat kalian.

#Kesalahan Umum dalam Mengelola Systemd

Kesalahan	Gejala	Solusi
Lupa `[Install]` + `enable`	Service berjalan, tapi hilang saat reboot	Tambah `WantedBy`, lalu `systemctl enable`
Tidak ada `Restart=`	Service mati tanpa dipulihkan	Set `Restart=on-failure` (atau `always`)
`Type=forking` tanpa `PIDFile`	Status "active" palsu, restart gagal	Sertakan `PIDFile` atau ganti `Type=simple`
Edit unit tanpa `daemon-reload`	Perubahan diabaikan	`systemctl daemon-reload` dulu
Menjalankan service sebagai root	Blast radius besar jika aplikasi diretas	Set `User=` khusus
`kill -9` manual pada service	systemd mengira service mati mendadak	Biarkan `systemctl stop` (kirim SIGTERM)
Log hanya di memori	Sejarah log hilang setelah reboot	Aktifkan persistensi journal di `/var/log/journal`

Satu pola yang sering membuat admin bingung: membunuh proses service secara manual dengan kill -9 <PID>. Systemd akan mendeteksi proses utama mati dan, karena Restart=on-failure aktif, menyalakan ulang service — kalian jadi heran kenapa "proses yang sudah dibunuh" muncul lagi. Jangan lawan systemd; gunakan systemctl stop untuk menghentikan service secara resmi, atau systemctl restart jika tujuannya hanya me-restart.

#Penutup

Pada episode 14 ini kalian telah memegang kendali atas systemd: memahami mengapa ia menggantikan SysVinit/Upstart sebagai init system, mengelola service dengan systemctl (start/stop/restart/reload/enable), membaca log terpusat dengan journalctl (filter -u, -f, -n, --since), dan menulis file unit service sendiri lengkap dengan tiga bagian [Unit], [Service], [Install]. Pelajaran terpenting: systemd mengubah aplikasi dari "proses yang dijalankan manual" menjadi warga sistem yang terawat — selalu jalan, selalu dipantau, dan selalu punya jejak log.

Namun, service yang berjalan sempurna pun tidak berguna jika disknya penuh. Di episode 15 selanjutnya kita akan membahas manajemen storage, disk & filesystem — membaca kapasitas dengan df/du/free, mempartisi dan memformat disk dengan fdisk/mkfs, memount dan mempersistenkan lewat /etc/fstab, hingga mengenal LVM dengan dynamic resize tanpa downtime. Sampai jumpa!