Troubleshooting Services

Pukul tiga pagi, alarm berbunyi: service yang kita tulis kemarin mati, dan yang paling jelas di kepala hanya keinginan mengetik restart berulang-ulang. Tindakan itu jarang menolong, karena setiap restart menghapus jejak justru pada saat kita paling membutuhkannya. Kabar baiknya: systemd mencatat hampir semua yang terjadi, sehingga diagnosis service gagal start bisa mengikuti prosedur yang konsisten. Chapter pamungkas section ini merangkum kerangka diagnosisnya, membaca kode error pada systemctl status, lalu memakai systemd-analyze verify untuk menangkap kesalahan unit sebelum dijalankan.

Kerangka Empat Langkah #

Ketika sebuah service tidak berperilaku sebagaimana mestinya, urutan pemeriksaan berikut hampir selalu sampai ke akar masalah:

1. Kenali gejalanya dengan systemctl status nama.service — baca baris Active dan kode error di bawahnya.
2. Baca log terkait dengan journalctl -u nama.service -e (materi lengkap Chapter journalctl ) — pesan error pemberani hampir selalu ada di baris terakhir.
3. Periksa konfigurasi dan lingkungannya: file unit, path di ExecStart, bit eksekusi, isi EnvironmentFile, kepemilikan file.
4. Perbaiki, lalu ulangi dengan benar: daemon-reload bila unitnya diedit, restart, dan cek status lagi dari langkah pertama.

Langkah pertama menuntut kita hafal kosakata status. Lima keadaan ini yang paling sering muncul:

Selain keadaan, systemctl status juga melaporkan cara proses berakhir di dalam kurung: status=1/FAILURE berarti aplikasi keluar sendiri dengan exit code 1, code=killed signal=KILL berarti proses dibunuh SIGKILL, dan status=203/EXEC berarti systemd sendiri yang gagal — binary di ExecStart tidak bisa dieksekusi, entah karena path salah atau hilangnya bit eksekusi.

Membaca status Unit yang Gagal #

Mari kita lihat wujud kegagalan yang sehat — status lengkap beserta lognya. Berikut contoh tampilan systemctl status nginx.service saat konfigurasi rusak:

× nginx.service - A high performance web server and reverse proxy server
     Loaded: loaded (/lib/systemd/system/nginx.service; enabled; preset: enabled)
     Active: failed (Result: exit-code) since Sat 2026-01-17 06:12:44 WIB; 5s ago
    Process: 9121 ExecStartPre=/usr/sbin/nginx -t (code=exited, status=1/FAILURE)
        CPU: 23ms
Jan 17 06:12:44 server-kantor nginx[9121]: nginx: [emerg] open() "/etc/nginx/conf.d/tidak-ada.conf" failed (2: No such file or directory)
Jan 17 06:12:44 server-kantor systemd[1]: nginx.service: Failed with result 'exit-code'.

Tiga baris pertama sudah membentuk cerita utuh: tanda × dan Active: failed menyatakan kegagalannya, ExecStartPre yang berstatus status=1/FAILURE menunjuk tahap yang gagal — nginx memang menguji konfigurasinya sebelum start — dan dua baris terakhir, cuplikan log yang dijual status begitu rupa, menyebut tersangka persisnya: file tidak-ada.conf yang dirujuk nginx.conf. Dari satu layar ini kita tahu harus ke mana: periksa baris 38 di konfigurasi nginx. Bila cuplikannya kurang, journalctl -u nginx.service -e menampilkan kegagalan yang sama lengkap dengan konteks sebelumnya.

Menangkap Kesalahan Sebelum Restart #

Sebagian besar kegagalan service sebenarnya bisa ditangkap lebih awal, sebelum restart pertama. systemd-analyze verify memeriksa file unit secara statis: sintaks section, path absolut, sampai keberadaan dan bit eksekusi binary di ExecStart. Kita simulasikan unit yang paling sering gagal — binary yang tidak ada:

cat > rusak.service << 'EOF'
[Unit]
Description=Service rusak untuk latihan diagnosis

[Service]
ExecStart=/usr/bin/tidur 30

[Install]
WantedBy=multi-user.target
EOF

systemd-analyze verify rusak.service 2>&1

Output yang Dihasilkan:

rusak.service: Command /usr/bin/tidur is not executable: No such file or directory

Blok di atas memang sengaja gagal — exit code-nya 1, dan verifikator materi ini menuntutnya. Mari kita bedah komponennya:

1. Baris 6 (ExecStart=/usr/bin/tidur 30): satu-satunya baris yang bermasalah — binary tidur tidak pernah ada di sistem Linux.
2. Baris 12 (systemd-analyze verify rusak.service 2>&1): stderr digabungkan ke stdout dengan 2>&1 agar pesan errornya ikut tercetak sebagai output blok.
3. Pesan hasilnya: Command /usr/bin/tidur is not executable: No such file or directory — persis keluhan yang akan muncul di journal saat unit seperti ini dinyalakan di mesin nyata, di mana wujudnya status=203/FAILURE pada systemctl status.

Perbaiki satu kata di ExecStart, dan unit yang sama langsung lolos:

cat > rusak.service << 'EOF'
[Unit]
Description=Service rusak untuk latihan diagnosis

[Service]
ExecStart=/usr/bin/tidur 30

[Install]
WantedBy=multi-user.target
EOF

sed -i 's|/usr/bin/tidur|/usr/bin/sleep|' rusak.service
systemd-analyze verify rusak.service && echo "unit sekarang lolos verifikasi"

Output yang Dihasilkan:

unit sekarang lolos verifikasi

Varian kedua yang sama seringnya: binary ada tetapi tidak executable — lupa chmod +x, persis skrip yang kita tulis di Chapter Menulis Service Unit :

printf '#!/bin/bash\necho "server mini siap"\n' > server-mini.sh
cat > perm.service << EOF
[Unit]
Description=Service tanpa izin eksekusi

[Service]
ExecStart=$PWD/server-mini.sh
EOF

systemd-analyze verify perm.service 2>&1

Output yang Dihasilkan:

perm.service: Command /home/budi/server-mini.sh is not executable: Permission denied

Path di blok ini memakai folder latihan Anda (di mesin penulis materi /home/budi) — satu-satunya beda dari pemasangan nyata di /usr/local/bin. Bedah singkatnya:

1. Baris 1 (printf ... > server-mini.sh): file baru hasil redirection hanya berizin baca-tulis — tidak ada bit eksekusi.
2. Baris 7 (ExecStart=$PWD/server-mini.sh): path benar dan filenya ada, jadi satu-satunya tersangka adalah izin eksekusi.
3. Pesan hasilnya: is not executable: Permission denied — beda satu kata dari kasus pertama (No such file or directory), dan keduanya adalah pasangan klasik: path salah versus bit eksekusi yang hilang.

Perlu dicatat batas verifikasi statis: verify tidak memeriksa user di User=, tidak membaca isi EnvironmentFile, dan tidak tahu apa pun tentang konfigurasi aplikasi — kesalahan di sana hanya muncul saat runtime, di journal.

Pola Penyakit Umum #

Setelah ratusan kegagalan, pola-pola ini muncul terus menerus. Tabel berikut merangkum gejala, tersangka, dan tindakan pertamanya:

Baris kelima layak dijelaskan: systemd membatasi kecepatan restart supaya crash loop tidak membakar CPU — bawaannya lima kali percobaan dalam sepuluh detik (StartLimitBurst dan StartLimitIntervalSec). Setelah batas itu tersentuh, systemd menyerah dan unit jatuh ke failed dengan pesan start request repeated too quickly. Perintah systemctl reset-failed nama.service menghapus status gagal beserta hitungannya agar percobaan bisa dimulai segar — tetapi ia hanya membuka pintu; akar masalahnya tetap harus diperbaiki.

Kerangka empat langkah ini menutup perjalanan kita bersama systemd: dari mengenali unit, mengelola service, menata target, membaca log, menulis unit sendiri, sampai membedah alur boot dan memulihkan yang gagal. Kemampuan berikutnya bukan lagi soal satu service, melainkan merawat sistem Linux secara utuh — dan itu pembuka Section System Administration , yang dimulai dari membedah proses boot dari sisi administrator. Panduan resmi debugging systemd terdokumentasi di systemd.io , opsi status dan reset-failed di systemctl(1) , dan struktur unit di systemd.service(5) .