Telusuri service Linux yang gagal atau tidak stabil dengan memeriksa state, exit status, time window, priority, dan field journal tanpa langsung melakukan restart.
Mengumpulkan bukti status dan log untuk satu systemd service, menemukan pesan yang paling relevan pada waktu kejadian, serta menentukan tindakan berikutnya berdasarkan hasil.
PersiapanMesin Linux yang menggunakan systemd, akses terminal, dan nama service yang boleh diperiksa. Beberapa log memerlukan sudo. Contoh memakai nginx.service; ganti dengan unit yang benar di host Anda dan jangan melakukan restart pada produksi tanpa prosedur perubahan.
Saat aplikasi tidak dapat diakses, respons umum adalah langsung me-restart service. Tindakan itu dapat menghilangkan kondisi yang perlu diamati dan belum tentu memperbaiki penyebab. Alur yang lebih aman adalah mencatat waktu, memastikan nama unit, membaca state serta exit status, lalu memfilter journal pada periode kejadian sebelum menentukan tindakan.
Contoh menggunakan nginx.service hanya sebagai nama unit yang mudah dikenali; perintah bukan hasil pengujian pada server nyata. Jalankan hanya pada sistem yang Anda kelola. Langkah di artikel bersifat read-only sampai bagian verifikasi. Jika akun tidak dapat membaca seluruh journal, gunakan sudo sesuai kebijakan organisasi—jangan mengubah permission hanya demi latihan.
Tujuan langkah ini adalah membuat log dapat dicocokkan dengan laporan pengguna atau monitoring. Perhatikan waktu lokal, UTC, timezone, dan status sinkronisasi. Hasil normal adalah jam host masuk akal dan sinkronisasi aktif. Jika waktu meleset, catat selisihnya sebelum mencari log karena event yang benar dapat terlihat berada di luar time window.
date
date -u
timedatectl statusNama proses tidak selalu sama dengan nama systemd unit. Cari unit service sebelum memfilter log. Perhatikan kolom UNIT, LOAD, ACTIVE, SUB, dan DESCRIPTION. Jika tidak ada hasil, periksa ejaan atau package yang digunakan; jangan menebak nama lalu menyimpulkan log kosong.
systemctl list-units --type=service --all | grep -i nginxContoh berikut hanya ilustrasi. loaded berarti definisi unit berhasil dimuat; active/running menunjukkan state saat command dijalankan, bukan bukti bahwa aplikasi melayani request dengan benar.
nginx.service loaded active running A high performance web serverGunakan is-active untuk state saat ini, is-enabled untuk konfigurasi saat boot, dan is-failed untuk mengetahui apakah unit berada pada failed state. Service dapat active tetapi tidak enabled, atau enabled tetapi sedang gagal. Exit code command juga berguna untuk script, namun baca teks state sebelum mengambil tindakan.
systemctl is-active nginx.service
systemctl is-enabled nginx.service
systemctl is-failed nginx.servicesystemctl status menggabungkan state unit, PID utama, waktu aktif, dan beberapa baris log terbaru. Perhatikan Loaded, Active, Main PID, Tasks, Memory, serta baris error. Hasil abnormal seperti Active: failed, code=exited, status non-zero, atau restart berulang menentukan bahwa pemeriksaan harus dilanjutkan ke journal. Jangan berhenti pada satu baris paling akhir jika penyebab muncul lebih awal.
systemctl status nginx.service --no-pager --fullPada contoh ini status=1/FAILURE membuktikan proses utama keluar gagal, tetapi belum menjelaskan penyebabnya. Langkah berikutnya adalah membuka log pada boot dan waktu kejadian.
Active: failed (Result: exit-code)
Process: 1420 ExecStart=/usr/sbin/nginx (code=exited, status=1/FAILURE)
Main PID: 1420 (code=exited, status=1/FAILURE)-u membatasi hasil ke satu unit dan -b membatasi ke boot saat ini. -o short-iso menampilkan timestamp yang mudah dikorelasikan. Hasil normal dapat memuat start sukses dan pesan operasi biasa. Jika tidak ada entry, pastikan nama unit, boot yang dipilih, permission, serta apakah aplikasi menulis ke journal atau file lain.
journalctl -u nginx.service -b --no-pager -o short-isoLog panjang sering membuat error penting terlewat. Gunakan --since dan --until dengan waktu yang mencakup gejala. Perhatikan pesan pertama sebelum rangkaian error, bukan hanya pesan terakhir. Jika time window kosong, lebarkan bertahap dan periksa timezone; jangan langsung menyimpulkan service tidak mencatat log.
journalctl -u nginx.service \
--since '2026-09-28 02:50:00' \
--until '2026-09-28 03:10:00' \
--no-pager -o short-isoOpsi -p warning menampilkan priority warning sampai emergency. Ini membantu triage, tetapi tidak boleh menjadi satu-satunya filter karena sebagian aplikasi menulis penyebab penting sebagai info. Jika hasil prioritas kosong sementara service gagal, kembali ke seluruh log dalam time window.
journalctl -u nginx.service -b -p warning --no-pager -o short-iso-n 50 mengambil 50 entry terbaru tanpa membuka seluruh journal. Gunakan ini untuk overview cepat lalu pindah ke time window yang tepat. Baris terbaru yang menunjukkan stop dapat merupakan akibat, sedangkan penyebab sebenarnya berada beberapa baris sebelumnya.
journalctl -u nginx.service -n 50 --no-pager -o short-isoGunakan -f hanya ketika Anda perlu mengamati event baru saat melakukan satu aksi aman yang sudah diizinkan, misalnya request health endpoint. Tekan Ctrl+C untuk berhenti. Normal berarti entry baru muncul pada timestamp aksi. Jika aplikasi merespons tetapi journal tetap diam, aplikasi mungkin menulis ke file, stdout yang diarahkan berbeda, atau logging-nya memang tidak mencatat request tersebut.
journalctl -u nginx.service -f -o short-isoOutput verbose membantu melihat metadata seperti _SYSTEMD_UNIT, _PID, PRIORITY, MESSAGE, dan timestamp. Field yang tersedia dapat berbeda. Gunakan metadata untuk memastikan pesan berasal dari unit dan proses yang benar. Jika _SYSTEMD_UNIT berbeda, jangan mengaitkan entry tersebut dengan service hanya karena teksnya mirip.
journalctl -u nginx.service -n 1 -o verbose --no-pagersystemctl show menampilkan property yang mudah dibandingkan tanpa memotong output status. Perhatikan ActiveState, SubState, Result, ExecMainCode, ExecMainStatus, dan NRestarts. Result=success serta status 0 biasanya normal. Status non-zero atau NRestarts yang terus bertambah menunjukkan failure loop; cari pesan tepat sebelum setiap restart dan hindari restart manual berulang.
systemctl show nginx.service \
-p ActiveState -p SubState -p Result \
-p ExecMainCode -p ExecMainStatus -p NRestartsContoh berikut menunjukkan unit gagal dengan exit status 1 dan sudah restart tiga kali. Angka itu perlu dikorelasikan dengan journal; angka restart sendiri tidak menjelaskan apakah penyebabnya konfigurasi, dependency, permission, port, atau resource.
ActiveState=failed
SubState=failed
Result=exit-code
ExecMainCode=1
ExecMainStatus=1
NRestarts=3Jika unit not-found, validasi nama/package. Jika inactive tetapi tidak failed, cek apakah service memang seharusnya berjalan dan lihat log stop. Jika failed dengan pesan konfigurasi, validasi konfigurasi memakai command resmi aplikasi sebelum start ulang. Jika ada permission denied, periksa path, ownership, policy keamanan, dan perubahan terbaru. Jika address already in use, identifikasi listener pemilik port. Jika active/running tetapi aplikasi tetap gagal, lanjutkan ke listener, dependency, DNS/TLS, atau log aplikasi—jangan menganggap systemd sehat berarti layanan end-to-end sehat.
Setelah penyebab diperbaiki melalui prosedur perubahan, ulangi is-active, status, journal time window, dan systemctl show. Normal berarti state sesuai desain, exit status tidak gagal, NRestarts tidak terus bertambah, dan fungsi aplikasi terverifikasi dari sisi client. Jangan mengklaim selesai hanya karena restart command berhasil.
systemctl is-active nginx.service
systemctl status nginx.service --no-pager --full
journalctl -u nginx.service --since '5 minutes ago' --no-pager -o short-isoJangan langsung restart sebelum menyimpan bukti. Jangan menyamakan enabled dengan running. Jangan membaca seluruh journal tanpa unit dan time filter. Jangan menganggap log kosong berarti tidak ada masalah sebelum memeriksa permission, boot, timezone, dan tujuan logging. Jangan hanya melihat priority error karena penyebab dapat dicatat sebagai warning atau info. Jangan membagikan log yang berisi hostname internal, username, token, path sensitif, atau data customer.
Catat waktu dan timezone; pastikan nama unit; bedakan active/enabled/failed; simpan Active, Result, exit status, PID, dan NRestarts; filter journal berdasarkan unit, boot, dan time window; baca pesan sebelum failure; periksa priority serta field terstruktur bila perlu; tentukan next step dari bukti; lalu verifikasi state service dan fungsi aplikasi setelah tindakan.
systemctl menjawab keadaan service, sedangkan journalctl membantu menjelaskan kejadian yang mengarah ke keadaan itu. Troubleshooting yang baik menggabungkan keduanya dalam timeline: identifikasi unit, ukur state, persempit log, interpretasikan pesan pertama yang relevan, lakukan satu tindakan yang disetujui, lalu verifikasi service dan aplikasi.