View source for Linux : Praktikum Membuat Service systemd dan Diagnosa Kegagalan Start

Artikel pagi sudah menjelaskan bahwa service adalah '''kontrak tertulis''' antara kamu dan systemd. Artikel ini menguji kontrak itu: apakah kontraknya benar-benar dijalankan, atau hanya terlihat rapi di atas kertas.

== 🎯 Tujuan ==

Setelah mengikuti praktikum ini, kamu bisa:

* membedakan "perintah start diterima" dari "pekerjaan benar-benar berjalan"
* membaca lima lapis bukti service sehat secara berurutan, tanpa menebak
* mengenali arti kode keluar <code>200</code>, <code>203</code>, <code>217</code>, dan <code>226</code>
* membedakan unit yang <code>failed</code> dari unit yang <code>skipped</code>
* memperbaiki service yang kena start limit tanpa menghapus unitnya
* menjelaskan ke guru atau atasan '''kenapa''' service gagal, bukan cuma "sudah saya restart"

== 📍 Konteks nyata ==

Bayangkan kamu menyerahkan shift jaga lab ke teman. Kamu bilang "sudah saya serahkan", lalu pergi. Temanmu bilang "sudah saya terima", lalu duduk. Tapi lampu lab belum dinyalakan, pintu belum dikunci, dan AC belum hidup.

Itulah yang terjadi kalau kamu hanya melihat <code>systemctl start</code> berhasil. Perintahnya diterima, serah terimanya sah, tapi belum ada bukti pekerjaannya jalan.

🔥 '''Kasus nyata:''' sebuah SMK punya service penyalin nilai ujian yang jalan tiap sore. Suatu hari skripnya dipindah ke folder lain dan <code>ExecStart=</code> tidak diubah. <code>systemctl start</code> tetap menjawab sukses karena unit memakai <code>Type=simple</code>. Tiga hari nilai tidak tersalin, dan panitia menuduh server rapornya rusak.

== 🧠 Konsep singkat ==

=== 🔹 Lima lapis bukti ===

Jangan melompat ke lapis berikutnya sebelum lapis sekarang terbukti. Kalau kamu melompat, kamu akan memperbaiki hal yang salah.

{| class="wikitable"
! Lapis !! Pertanyaan !! Alat bukti
|-
| 1 | Unit terbaca systemd? | <code>systemctl cat</code>, kolom <code>Loaded</code>
|-
| 2 | Perintahnya benar-benar dieksekusi? | <code>ExecMainStatus</code>, <code>Result</code>
|-
| 3 | Prosesnya hidup? | <code>MainPID</code>, <code>SubState</code>
|-
| 4 | Karyanya nyata? | file log, port listen, isi database
|-
| 5 | Bertahan setelah reboot? | <code>is-enabled</code>, uji reboot
|}

📊 '''Angka penting:''' <code>systemctl start</code> hanya menjawab satu hal, yaitu job sudah diterima. Ia tidak menjamin proses hidup, tidak menjamin pekerjaan selesai, dan tidak menjamin service hidup lagi setelah reboot.

=== 🔹 Kenapa Type=simple membohongi kamu ===

Pada <code>Type=simple</code>, systemd menganggap unit sudah "started" tepat setelah proses di-<code>fork()</code>. Binary-nya bahkan belum tentu berhasil di-<code>execve()</code>.

Dokumentasi resmi menyebutnya terang-terangan: perintah <code>systemctl start</code> untuk service <code>simple</code> akan melaporkan sukses walaupun binary-nya tidak bisa dijalankan, misalnya karena <code>User=</code> tidak ada atau file binary hilang.

Pada <code>Type=exec</code>, systemd menunggu sampai <code>execve()</code> berhasil. Di situlah kegagalan mulai terlihat di terminal, bukan cuma di journal.

=== 🔹 Kode keluar sistem adalah kode pos masalah ===

Kalau <code>ExecStart=</code> gagal sebelum programmu sempat jalan, systemd memberi kode khusus. Kode ini menunjuk lapis mana yang rusak.

{| class="wikitable"
! Kode !! Nama !! Arti
|-
| 200 | EXIT_CHDIR | Gagal pindah ke <code>WorkingDirectory=</code>
|-
| 203 | EXIT_EXEC | <code>execve()</code> gagal: file hilang atau tidak boleh dieksekusi
|-
| 216 | EXIT_GROUP | Gagal memakai <code>Group=</code>
|-
| 217 | EXIT_USER | Gagal memakai <code>User=</code>
|-
| 226 | EXIT_NAMESPACE | Gagal menyiapkan namespace
|}

🧪 '''Uji cepat:''' <code>systemd-analyze exit-status 200 203 217</code> menampilkan daftar kode yang dikenal systemd di mesinmu, tanpa harus menghafal.

=== 🔹 Start limit: kapan systemd berhenti mencoba ===

Kalau <code>Restart=</code> aktif dan service gagal terus, systemd tidak menyerah diam-diam. Ia menghitung percobaan start.

Bawaannya 5 kali start dalam 10 detik. Setelah itu unit dikunci dan <code>Result=</code> berubah menjadi <code>start-limit-hit</code>.

⚠️ '''Hati-hati:''' saat start limit tercapai, <code>systemctl start</code> menolak dengan pesan <code>start request repeated too quickly</code>. Banyak siswa panik lalu menghapus unit. Padahal cukup <code>systemctl reset-failed</code>, lalu perbaiki akar masalahnya.

== 🧩 Istilah penting ==

{| class="wikitable"
! Istilah !! Arti sederhana
|-
| Unit | File kontrak <code>.service</code> yang dibaca systemd
|-
| Drop-in | File tambahan di <code>nama.service.d/</code> untuk menimpa sebagian isi unit
|-
| <code>Result</code> | Hasil akhir eksekusi terakhir: <code>success</code>, <code>exit-code</code>, <code>timeout</code>, <code>start-limit-hit</code>
|-
| <code>ExecMainStatus</code> | Kode keluar proses utama pada eksekusi terakhir
|-
| <code>NRestarts</code> | Berapa kali systemd sudah merestart unit ini
|-
| <code>MainPID</code> | PID proses utama; <code>0</code> berarti tidak ada proses hidup
|-
| cgroup | Wadah kernel yang memuat semua proses milik unit
|-
| Condition | Syarat yang membuat unit dilewati, bukan digagalkan
|-
| <code>enable</code> | Membuat symlink agar unit ikut start saat boot
|-
| sd_notify | Panggilan dari program ke systemd untuk bilang "saya siap"
|}

== 🔧 Praktik: Membangun Layanan dan Membuktikannya ==

Lab ini memakai Debian 12 di VM. Ambil snapshot dulu, karena kita akan sengaja merusak unit berkali-kali.

Semua nama diberi awalan <code>lab-</code> supaya tidak bentrok dengan service asli sistem.

=== 🔹 Langkah 1: siapkan user dan skrip ===

Service yang rapi tidak jalan sebagai root. Kita buat user sistem khusus dan satu direktori log.

<syntaxhighlight lang="bash">
sudo useradd --system --no-create-home --shell /usr/sbin/nologin lab-lapor
sudo mkdir -p /var/log/lab-lapor
sudo chown lab-lapor:lab-lapor /var/log/lab-lapor
sudo chmod 750 /var/log/lab-lapor
</syntaxhighlight>

Lalu buat skrip yang benar-benar bekerja: mencatat suhu tiap 10 detik dan berhenti dengan sopan saat diminta.

<syntaxhighlight lang="bash">
sudo tee /usr/local/bin/lab-lapor.sh > /dev/null <<'EOF'
#!/bin/bash
set -u
LOG=/var/log/lab-lapor/suhu.log
trap 'echo "$(date "+%F %T") berhenti" >> "$LOG"; exit 0' TERM INT
while true; do
  SUHU=$(cut -c1-2 /sys/class/thermal/thermal_zone0/temp 2>/dev/null || echo "00")
  echo "$(date '+%F %T') suhu=${SUHU}C" >> "$LOG"
  sleep 10
done
EOF
sudo chmod 755 /usr/local/bin/lab-lapor.sh
</syntaxhighlight>

💡 '''Tips:''' di VM, <code>thermal_zone0</code> sering tidak ada. Skrip tetap jalan dan menulis <code>suhu=00C</code>. Yang kita uji adalah mekanisme service, bukan sensor.

=== 🔹 Langkah 2: tulis unit dengan sengaja lengkap ===

<syntaxhighlight lang="ini">
[Unit]
Description=Lab pencatat suhu (praktikum systemd)
After=network.target
StartLimitIntervalSec=20s
StartLimitBurst=3

[Service]
Type=exec
User=lab-lapor
Group=lab-lapor
WorkingDirectory=/var/log/lab-lapor
EnvironmentFile=-/etc/lab-lapor.conf
ExecStart=/usr/local/bin/lab-lapor.sh
Restart=on-failure
RestartSec=2s
NoNewPrivileges=yes
PrivateTmp=yes

[Install]
WantedBy=multi-user.target
</syntaxhighlight>

Simpan sebagai <code>/etc/systemd/system/lab-lapor.service</code>, lalu <code>sudo systemctl daemon-reload</code>.

Tanda minus pada <code>EnvironmentFile=-/etc/lab-lapor.conf</code> berarti "kalau file tidak ada, jangan gagal". Tanpa minus, unit langsung gagal saat file itu belum dibuat.

=== 🔹 Langkah 3: periksa sebelum start ===

<syntaxhighlight lang="bash">
sudo systemd-analyze verify /etc/systemd/system/lab-lapor.service
systemctl cat lab-lapor.service
systemctl show -p Type,User,Restart,StartLimitBurst lab-lapor.service
</syntaxhighlight>

Kalau <code>verify</code> tidak mengeluarkan apa pun, artinya tidak ada peringatan. Ini pemeriksaan termurah yang sering dilewatkan orang.

=== 🔹 Langkah 4: kumpulkan lima bukti ===

<syntaxhighlight lang="bash">
sudo systemctl start lab-lapor.service
systemctl status lab-lapor.service --no-pager
systemctl show -p Result,ExecMainStatus,MainPID,NRestarts lab-lapor.service
tail -n 3 /var/log/lab-lapor/suhu.log
journalctl -u lab-lapor.service -b --no-pager -n 15
</syntaxhighlight>

Yang harus kamu lihat: <code>Active: active (running)</code>, <code>Result=success</code>, <code>MainPID</code> berisi angka, dan file log bertambah tiap 10 detik.

=== 🔹 Langkah 5: buktikan bertahan setelah reboot ===

<syntaxhighlight lang="bash">
sudo systemctl enable --now lab-lapor.service
systemctl is-enabled lab-lapor.service
sudo reboot
</syntaxhighlight>

Setelah masuk lagi, jalankan <code>systemctl is-active lab-lapor</code> dan lihat file log. Kalau <code>active</code> dan log bertambah tanpa kamu sentuh, baru layak disebut service.

🧪 '''Uji cepat:''' <code>systemctl list-units --failed</code> harus kosong sebelum kamu mulai merusak apa pun. Baseline bersih membuat setiap kegagalan berikutnya jelas berasal dari ulahmu.

=== 🔹 Uji A: binary tidak ada, dan janji Type=simple ===

Ubah lewat drop-in, bukan dengan mengedit file utama.

<syntaxhighlight lang="bash">
sudo systemctl edit --force --full lab-lapor.service
</syntaxhighlight>

Ganti sementara <code>Type=exec</code> menjadi <code>Type=simple</code> dan arahkan <code>ExecStart=</code> ke file yang tidak ada:

<syntaxhighlight lang="ini">
Type=simple
ExecStart=/usr/local/bin/lab-lapor-salah.sh
</syntaxhighlight>

Lalu:

<syntaxhighlight lang="bash">
sudo systemctl daemon-reload
sudo systemctl start lab-lapor.service; echo "exit=$?"
sleep 2
systemctl status lab-lapor.service --no-pager
systemctl show -p Result,ExecMainStatus lab-lapor.service
</syntaxhighlight>

Hasil yang khas: <code>echo "exit=$?"</code> mencetak <code>0</code>, tetapi status menunjukkan <code>failed</code> dengan <code>status=203/EXEC</code>.

Sekarang ubah kembali ke <code>Type=exec</code> dengan path yang sama salahnya. Perintah <code>start</code> langsung gagal dan terminal menampilkan pesan error, bukan sukses palsu.

Itulah bedanya: <code>simple</code> melaporkan "sudah saya fork", <code>exec</code> melaporkan "binary sudah benar-benar jalan".

=== 🔹 Uji B: user tidak ada (217/USER) ===

<syntaxhighlight lang="bash">
sudo systemctl edit --force --full lab-lapor.service
</syntaxhighlight>

Ganti <code>User=lab-lapor</code> menjadi <code>User=lab-lapoor</code> (salah ketik satu huruf), lalu <code>daemon-reload</code> dan <code>start</code>.

Bukti:

<syntaxhighlight lang="bash">
systemctl show -p Result,ExecMainStatus lab-lapor.service
journalctl -u lab-lapor.service -b --no-pager -n 10
</syntaxhighlight>

<code>Result=exit-code</code>, <code>ExecMainStatus=217</code>, dan journal menyebut user tidak dikenal.

💡 '''Tips:''' <code>217</code> hampir selalu berarti salah ketik nama user, bukan masalah izin file. Cek dengan <code>id lab-lapoor</code> sebelum menyalahkan sistem.

=== 🔹 Uji C: working directory hilang (200/CHDIR) ===

Ganti <code>WorkingDirectory=/var/log/lab-lapor</code> menjadi <code>/srv/tidak-ada</code>.

<syntaxhighlight lang="bash">
systemctl show -p Result,ExecMainStatus lab-lapor.service
</syntaxhighlight>

<code>ExecMainStatus=200</code> muncul sebelum skripmu sempat berjalan. Artinya kegagalan ada di lapis 2, bukan di dalam skrip.

⚠️ '''Hati-hati:''' jangan menambahkan <code>WorkingDirectory=-/srv/tidak-ada</code> hanya agar "tidak error". Tanda minus membuat systemd diam saja, dan skripmu jalan di direktori yang salah. Gejalanya berubah jadi bug yang jauh lebih mahal.

=== 🔹 Uji D: ExecStart relatif ===

Tulis <code>ExecStart=lab-lapor.sh</code> tanpa path absolut.

<syntaxhighlight lang="bash">
sudo systemd-analyze verify /etc/systemd/system/lab-lapor.service
sudo systemctl daemon-reload
sudo systemctl start lab-lapor.service
</syntaxhighlight>

<code>verify</code> memberi peringatan bahwa path executable bukan absolut. Unit masuk keadaan <code>bad-setting</code>, dan <code>start</code> ditolak sebelum apa pun dijalankan.

Aturannya sederhana: systemd tidak memakai <code>$PATH</code> milik shellmu. Selalu tulis path lengkap.

=== 🔹 Uji E: exit 1 berulang dan start limit ===

Buat skrip yang sengaja gagal:

<syntaxhighlight lang="bash">
sudo tee /usr/local/bin/lab-gagal.sh > /dev/null <<'EOF'
#!/bin/bash
echo "gagal dijalankan pada $(date '+%F %T')"
exit 1
EOF
sudo chmod 755 /usr/local/bin/lab-gagal.sh
</syntaxhighlight>

Arahkan <code>ExecStart=</code> ke skrip itu, biarkan <code>Restart=on-failure</code> dan <code>RestartSec=2s</code>, lalu:

<syntaxhighlight lang="bash">
sudo systemctl daemon-reload
sudo systemctl start lab-lapor.service
sleep 20
systemctl status lab-lapor.service --no-pager
systemctl show -p Result,NRestarts lab-lapor.service
</syntaxhighlight>

Setelah tiga percobaan dalam 20 detik, unit berhenti dicoba. <code>Result=start-limit-hit</code>, dan <code>NRestarts</code> menunjukkan jumlah restart yang sudah terjadi.

Sekarang coba start lagi:

<syntaxhighlight lang="bash">
sudo systemctl start lab-lapor.service
</syntaxhighlight>

Muncul penolakan <code>start request repeated too quickly</code>. Ini bukan kerusakan; ini pengaman agar server tidak sibuk me-restart selamanya.

<syntaxhighlight lang="bash">
sudo systemctl reset-failed lab-lapor.service
</syntaxhighlight>

Setelah direset, unit bisa dicoba lagi. Tapi ingat: yang kamu reset hanya penghitungnya, bukan penyebabnya.

=== 🔹 Uji F: port sudah dipakai ===

Kegagalan di dalam program berbeda rasanya. Program jalan, lalu keluar sendiri karena sumber daya tidak tersedia.

<syntaxhighlight lang="bash">
sudo apt install -y python3
python3 -m http.server 8080 &
</syntaxhighlight>

Buat unit kedua:

<syntaxhighlight lang="ini">
[Unit]
Description=Lab web statis
After=network.target

[Service]
Type=exec
User=lab-lapor
WorkingDirectory=/var/log/lab-lapor
ExecStart=/usr/bin/python3 -m http.server 8080
Restart=on-failure
RestartSec=2s

[Install]
WantedBy=multi-user.target
</syntaxhighlight>

Simpan sebagai <code>/etc/systemd/system/lab-web.service</code>, lalu <code>daemon-reload</code> dan <code>start</code>.

Bukti: <code>Result=exit-code</code>, <code>ExecMainStatus=1</code>, dan journal memuat <code>Address already in use</code>. Perbaikannya bukan mengubah unit, tapi membebaskan port: matikan proses <code>python3</code> yang kamu jalankan manual tadi.

📊 '''Angka penting:''' <code>ExecMainStatus=0</code> berarti program keluar dengan sengaja dan bersih. Untuk service yang seharusnya hidup terus, itu juga kegagalan logika, meskipun bukan kegagalan sistem.

=== 🔹 Uji G: Condition membuat unit di-skip, bukan gagal ===

Tambahkan syarat lewat drop-in:

<syntaxhighlight lang="ini">
[Unit]
ConditionPathExists=/srv/data-laporan
</syntaxhighlight>

Direktori itu belum ada. Lalu <code>daemon-reload</code> dan <code>start</code>.

<syntaxhighlight lang="bash">
systemctl status lab-lapor.service --no-pager
systemctl show -p ConditionResult,ActiveState lab-lapor.service
</syntaxhighlight>

Statusnya <code>inactive (dead)</code> dengan <code>ConditionResult=no</code>, bukan <code>failed</code>. Perintah <code>start</code> pun tidak melaporkan error.

⚠️ '''Hati-hati:''' inilah kegagalan paling berbahaya. Tidak ada alarm, tidak ada unit merah, dan monitoring yang hanya memeriksa <code>is-failed</code> akan tidur nyenyak sementara pekerjaan tidak pernah jalan.

Perbaikannya: buat direktori yang diminta, atau ganti pendekatan menjadi <code>RequiresMountsFor=</code> bila syaratnya adalah mount.

=== 🔹 Uji H: Type=notify tanpa sd_notify ===

Program yang tidak pernah mengirim <code>READY=1</code> akan membuat systemd menunggu.

<syntaxhighlight lang="ini">
[Service]
Type=notify
TimeoutStartSec=10s
</syntaxhighlight>

<code>TimeoutStartSec</code> dinaikkan-turunkan hanya untuk lab. Bawaannya 90 detik, jadi tanpa ini kamu menunggu satu setengah menit per percobaan.

Setelah <code>daemon-reload</code> dan <code>start</code>, tunggu sepuluh detik. Hasilnya <code>Result=timeout</code> dan pesan start operation timed out. Proses dibunuh walaupun skripnya sehat.

💡 '''Tips:''' <code>Type=notify</code> hanya untuk program yang benar-benar memanggil <code>sd_notify()</code>. Kalau kamu menyalin contoh dari internet tanpa memeriksa itu, kamu sedang membuat kegagalan baru.

=== 🔹 Uji I: enable tanpa [Install] ===

Buat unit ketiga tanpa bagian <code>[Install]</code>:

<syntaxhighlight lang="ini">
[Unit]
Description=Lab tanpa install

[Service]
Type=oneshot
ExecStart=/usr/bin/true
</syntaxhighlight>

Simpan sebagai <code>lab-tanpa-install.service</code>, lalu:

<syntaxhighlight lang="bash">
sudo systemctl daemon-reload
sudo systemctl start lab-tanpa-install.service
sudo systemctl enable lab-tanpa-install.service
systemctl is-enabled lab-tanpa-install.service
</syntaxhighlight>

<code>start</code> berhasil, tetapi <code>enable</code> menjawab bahwa unit tidak punya konfigurasi instalasi. <code>is-enabled</code> mengembalikan <code>static</code>.

Artinya: service bisa dijalankan manual, tapi tidak akan pernah ikut boot. Ini penyebab paling umum dari kalimat "kemarin jalan, pagi ini mati".

=== 🔹 Lembar hasil sembilan uji ===

{| class="wikitable"
! Uji !! Gejala kunci !! Bukti utama
|-
| A | start sukses tapi unit merah | <code>203</code> di <code>ExecMainStatus</code>
|-
| B | gagal sebelum skrip jalan | <code>217</code>
|-
| C | gagal sebelum skrip jalan | <code>200</code>
|-
| D | start ditolak | <code>LOAD: bad-setting</code>
|-
| E | start ditolak setelah beberapa detik | <code>Result=start-limit-hit</code>
|-
| F | program keluar sendiri | <code>ExecMainStatus=1</code>
|-
| G | diam, tidak merah | <code>ConditionResult=no</code>
|-
| H | start menggantung lalu gagal | <code>Result=timeout</code>
|-
| I | jalan manual, mati setelah boot | <code>is-enabled</code> = <code>static</code>
|}

== 🏭 Dipakai di dunia kerja ==

* '''Sekolah dan lab CBT:''' layanan penyalin nilai serta penjadwal ujian harus <code>enable</code> dan punya <code>Restart=on-failure</code>. Kegagalan senyap di sini langsung terasa oleh ratusan siswa.
* '''Kantor distributor dan retail:''' service sinkron stok ke ERP. Salah <code>Type=</code> membuat systemd merestart program yang sebenarnya sedang bekerja, dan stok tercatat dua kali.
* '''Klinik dan rumah sakit:''' service backup ke disk eksternal. Syarat mount yang salah membuat backup berhenti berminggu-minggu tanpa satu pun alarm berbunyi.
* '''ISP dan RT-RW Net:''' service monitoring pelanggan. Start limit yang tercapai menyembunyikan masalah uplink, karena unitnya sudah "menyerah" lebih dulu daripada jaringan.
* '''Industri:''' gateway data mesin ke MQTT. Di sini urutan <code>After=</code> dan kesiapan dependency menentukan apakah data hilang saat listrik pulih.
* '''Cloud dan VPS:''' aplikasi internal kecil lebih jujur dijalankan sebagai unit systemd daripada skrip di dalam <code>screen</code> yang lupa dipasang lagi setelah maintenance.

== ✅ Verifikasi ==

Jalankan ini pada unit yang sehat, lalu simpan hasilnya sebagai baseline.

{| class="wikitable"
! Perintah !! Hasil yang diharapkan
|-
| <code>systemd-analyze verify /etc/systemd/system/lab-lapor.service</code> | tanpa keluaran
|-
| <code>systemctl is-enabled lab-lapor</code> | <code>enabled</code>
|-
| <code>systemctl is-active lab-lapor</code> | <code>active</code>
|-
| <code>systemctl show -p Result,ExecMainStatus,MainPID</code> | <code>success</code>, <code>0</code>, PID angka
|-
| <code>systemctl list-units --failed</code> | kosong
|-
| <code>tail -n 3 /var/log/lab-lapor/suhu.log</code> | baris bertambah tiap 10 detik
|-
| <code>journalctl -u lab-lapor -b --no-pager -n 20</code> | tanpa pesan error berulang
|}

🧪 '''Uji cepat:''' setelah reboot, cocokkan waktu baris terakhir di file log dengan <code>uptime</code>. Kalau log berhenti tepat saat mesin mati, service-mu tidak ikut boot.

== ⚠️ Kesalahan umum & troubleshooting ==

{| class="wikitable"
! Gejala !! Periksa dulu !! Penyebab biasa
|-
| start sukses, status merah | <code>show -p Result,ExecMainStatus</code> | <code>Type=simple</code> menelan kegagalan exec
|-
| <code>203/EXEC</code> | <code>ls -l</code> path dan baris shebang | path salah, tidak executable, shebang hilang
|-
| <code>217/USER</code> | <code>id nama-user</code> | user belum dibuat atau salah ketik
|-
| <code>200/CHDIR</code> | <code>ls -ld</code> direktori kerja | direktori belum ada atau tidak bisa diakses user
|-
| <code>bad-setting</code> | <code>systemctl cat</code> | path relatif atau dua baris <code>ExecStart=</code>
|-
| start ditolak "too quickly" | <code>show -p NRestarts,Result</code> | start limit tercapai
|-
| unit diam, tidak merah | <code>show -p ConditionResult</code> | Condition tidak terpenuhi
|-
| <code>Result=timeout</code> | <code>journalctl -u ... -b</code> | <code>Type=notify</code> tanpa <code>sd_notify</code>
|-
| mati setelah reboot | <code>systemctl is-enabled</code> | belum enable atau tidak ada <code>[Install]</code>
|-
| perubahan unit tidak berlaku | <code>systemctl cat</code> | lupa <code>daemon-reload</code>
|}

* ⚠️ '''Hati-hati:''' <code>systemctl restart</code> yang diulang sepuluh kali bukan diagnosis. Ia hanya menghapus bukti dari eksekusi sebelumnya, karena status terakhir menimpa yang lama.
* 📊 '''Angka penting:''' default <code>TimeoutStartSec</code> adalah 90 detik, dan start limit bawaan 5 percobaan per 10 detik. Dua angka ini menjelaskan sebagian besar laporan "service-nya menggantung".
* 🔥 '''Kasus nyata:''' sebuah kantor distributor menyalin contoh unit <code>Type=notify</code> dari internet. Setiap pagi service antrean cetak menunggu 90 detik, dianggap gagal, lalu dijalankan ulang. Selama seminggu struk tercetak ganda, dan tim menyalahkan aplikasi kasir yang tidak pernah salah.

== 🔐 Catatan keamanan & etika ==

* File di <code>/etc/systemd/system/</code> setara akses root saat unit dijalankan. Siapa pun yang bisa menulis ke folder itu bisa menjalankan perintah sebagai root pada boot berikutnya.
* Jangan menaruh password di <code>ExecStart=</code>. Isinya terlihat di <code>ps aux</code> dan di <code>systemctl cat</code>. Pakai <code>EnvironmentFile=</code> dengan mode <code>600</code> milik root.
* Biasakan <code>User=</code>, <code>NoNewPrivileges=yes</code>, dan <code>PrivateTmp=yes</code>. Untuk layanan yang hanya menulis satu folder, tambahkan <code>ProtectSystem=strict</code> plus <code>ReadWritePaths=</code>.
* <code>ConditionPathExists=</code> bukan pengganti penanganan error. Unit yang dilewati tidak memberi alarm, jadi pastikan monitoring memeriksa hasil kerja, bukan hanya status unit.
* Di server bersama, <code>journalctl</code> bisa memuat log milik layanan orang lain. Baca hanya unit yang menjadi tanggung jawabmu, dan jangan mengubah service milik orang lain tanpa izin.
* Etika lab: semua uji rusak di artikel ini dilakukan di VM dengan snapshot. Jangan pernah melatih <code>exit 1</code> dan start limit di server produksi.

== 📌 Kesimpulan ==

Service yang sehat bukan yang berhasil di-<code>start</code>, tapi yang bisa kamu buktikan di lima lapis: unit terbaca, perintah dieksekusi, proses hidup, karya nyata, dan bertahan setelah reboot.

Kode keluar memberitahu lapis mana yang rusak. <code>200</code> berarti direktori, <code>203</code> berarti binary, <code>217</code> berarti user. Kalau semuanya benar tapi unit tetap diam, periksa <code>ConditionResult</code> sebelum menuduh apa pun.

Langkah berikutnya: ambil satu service nyata di labmu, catat <code>Result</code>, <code>ExecMainStatus</code>, dan <code>NRestarts</code>-nya hari ini, lalu bandingkan setelah satu minggu.

== 🔗 Materi terkait ==

* [[Linux : Membuat Service Sendiri dengan systemd]] — artikel pagi: isi kontrak dan bagian-bagian unit
* [[Linux : Cara Membaca Penyebab Service Gagal Start dengan systemctl status dan journalctl]] — dasar membaca status dan log
* [[Linux : Cek Service yang Sedang Berjalan]] — inventaris unit aktif sebelum mulai mengubah
* [[Linux : Manajemen Paket dan Repositori Debian]] — memasang paket yang menyediakan binary untuk unitmu
* [[Linux: Cron Job]] — pilihan lain untuk tugas terjadwal yang tidak perlu hidup terus
* [[Linux : Permission File dan Folder]] — akar dari banyak kegagalan <code>200</code> dan <code>203</code>

== 📚 Referensi ==

* systemd.service(5) — tipe service, <code>Restart=</code>, <code>RestartSec=</code>, <code>TimeoutStartSec=</code>: https://manpages.debian.org/bookworm/systemd/systemd.service.5.en.html
* systemd.exec(5) — bagian Process Exit Codes (<code>200</code>, <code>203</code>, <code>216</code>, <code>217</code>, <code>226</code>): https://manpages.debian.org/bookworm/systemd/systemd.exec.5.en.html
* systemd.unit(5) — <code>StartLimitIntervalSec=</code>, <code>StartLimitBurst=</code>, drop-in, dan urutan pencarian unit: https://manpages.debian.org/bookworm/systemd/systemd.unit.5.en.html
* systemd-system.conf(5) — default <code>DefaultTimeoutStartSec=90s</code> dan <code>DefaultStartLimitBurst=5</code>: https://manpages.debian.org/bookworm/systemd/systemd-system.conf.5.en.html
* systemctl(1) — <code>status</code>, <code>show</code>, <code>is-failed</code>, <code>reset-failed</code>: https://manpages.debian.org/bookworm/systemd/systemctl.1.en.html
* systemd-analyze(1) — <code>verify</code> dan <code>exit-status</code>: https://manpages.debian.org/bookworm/systemd/systemd-analyze.1.en.html

[[Category:TKJ]]
[[Category:Linux]]
[[Category:Server]]
[[Category:Systemd]]