Cara Cek journald Menyimpan Log Permanen Setelah Pindah dari rsyslog

Server yang dulu menulis log ke /var/log/messages lewat rsyslog sekarang hanya punya journald. Bisa karena rsyslog sengaja dicopot, bisa juga karena image barunya memang tidak memasang rsyslog. Lalu server restart sendiri tengah malam, kamu jalankan journalctl -b -1 untuk melihat apa yang terjadi sebelum reboot, dan hasilnya kosong atau malah muncul pesan bahwa persistent journal tidak ditemukan. Log-nya tidak dihapus siapa pun. Dari awal log itu memang cuma disimpan di memori. Artikel ini fokus ke verifikasi lewat CLI: cara memastikan journald benar-benar menulis ke disk, cara mengaktifkannya kalau belum, lalu cara membuktikannya setelah reboot.

Kenapa journal bisa hilang setelah reboot

journald punya dua lokasi penyimpanan. Yang pertama /run/log/journal, dan /run itu tmpfs, yaitu filesystem yang hidup di RAM. Yang kedua /var/log/journal di disk. Kapan journald memakai yang mana ditentukan oleh opsi Storage= di bagian [Journal] pada konfigurasinya. Nilai yang umum dipakai sebagai default adalah auto. Dengan auto, journald akan menulis ke disk kalau folder /var/log/journal sudah ada. Kalau foldernya tidak ada, journald diam-diam memakai /run/log/journal. Tidak ada error dan tidak ada warning. Opsi lainnya adalah persistent (selalu ke disk, folder dibuat otomatis kalau belum ada), volatile (selalu di RAM), dan none (tidak menyimpan sama sekali). Waktu masih ada rsyslog, kondisi ini jarang disadari. journald mungkin cuma menyimpan di RAM, tapi rsyslog tetap menulis salinannya ke /var/log/messages atau /var/log/syslog. Begitu rsyslog hilang, salinan di disk itu ikut hilang, dan journal yang volatile jadi satu-satunya sumber log. Di meja support, pola ini sering muncul sebagai pertanyaan "kenapa log sebelum restart tidak ada?", terutama setelah upgrade OS atau migrasi ke VPS baru. Ini penting kalau kamu sedang menyelidiki kenapa sebuah proses mati atau server reboot. Pesan kernel seperti OOM killer juga ikut hilang setelah reboot kalau journal-nya volatile. Topik membaca pesan OOM itu sendiri sudah dibahas di Membaca Log dmesg untuk Memastikan Aplikasi Dimatikan OOM Killer.

Cek kondisi sekarang sebelum mengubah apa pun

Jangan langsung mengedit file. Pastikan dulu journald saat ini menulis ke mana dan konfigurasi apa yang sebenarnya aktif. Semua perintah di bawah ini read-only:

BASH

# 1. Ada berapa boot yang tercatat?
journalctl --list-boots

# 2. Folder mana yang ada dan berisi journal?
ls -ld /var/log/journal /run/log/journal

# 3. Berapa besar journal yang tersimpan sekarang?
journalctl --disk-usage

# 4. Nilai Storage yang efektif, termasuk dari file drop-in
systemd-analyze cat-config systemd/journald.conf | grep -i '^Storage'

Cara membaca hasilnya kurang lebih begini. journalctl --list-boots yang cuma menampilkan satu baris dengan indeks 0 berarti hanya boot saat ini yang tercatat. Kalau server sudah beberapa kali reboot dan daftarnya tetap satu baris, itu tanda kuat journal-nya volatile. Dari ls -ld, kalau /var/log/journal tidak ada (No such file or directory) sementara /run/log/journal ada, journald sedang menulis ke RAM. Kalau keduanya ada, cek isinya. Di dalam /var/log/journal seharusnya ada subfolder bernama machine-id server, yang isinya sama dengan /etc/machine-id, berisi file berekstensi .journal. Perintah keempat yang paling sering dilewatkan. systemd-analyze cat-config menampilkan gabungan journald.conf utama beserta semua drop-in dari /etc/systemd/journald.conf.d/, /run/systemd/journald.conf.d/, dan /usr/lib/systemd/journald.conf.d/. Drop-in itu file konfigurasi tambahan yang menimpa nilai di file utama. Beberapa distro atau image cloud bisa menaruh Storage=volatile di salah satu drop-in, dan nilai itu menang walaupun file utamanya bilang lain. Kalau grep tidak menemukan baris Storage yang aktif (baris yang dikomentari dengan # tidak ikut), berarti yang berlaku adalah default bawaan versi systemd kamu. Biasanya auto, tapi pastikan lewat man journald.conf di server tersebut.

Mengaktifkan penyimpanan permanen dengan aman

Ada dua cara yang sama-sama sah. Cara pertama cukup membuat folder /var/log/journal dan membiarkan Storage=auto bekerja. Cara kedua menyatakannya secara eksplisit dengan Storage=persistent. Aku pribadi lebih suka cara kedua lewat drop-in. Niatnya tertulis jelas di konfigurasi, tidak tertimpa saat paket systemd di-upgrade, dan tidak bergantung pada keberadaan folder yang bisa saja terhapus. Perintah di bawah ini mengubah konfigurasi sistem, jadi jalankan dengan sadar. Langkah-langkahnya tidak menghapus log yang sudah ada.

BASH

# Buat drop-in yang menyatakan Storage=persistent
sudo mkdir -p /etc/systemd/journald.conf.d
printf '[Journal]
Storage=persistent
' | sudo tee /etc/systemd/journald.conf.d/persistent.conf

# Buat folder journal dengan owner, group, dan ACL yang benar
sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal

# Minta journald memindahkan journal dari /run ke /var/log/journal
sudo journalctl --flush

Sedikit penjelasan untuk tiap langkah. systemd-tmpfiles --create --prefix /var/log/journal membaca aturan tmpfiles bawaan systemd untuk path itu, lalu menerapkan group systemd-journal, permission, dan ACL yang seharusnya. Ini lebih aman daripada mengatur chown atau chmod manual karena aturannya mengikuti versi systemd yang terpasang. Kalau permission-nya salah, journald bisa gagal menulis, atau user non-root di group systemd-journal jadi tidak bisa membaca log. journalctl --flush meminta journald memindahkan isi /run/log/journal ke /var/log/journal. Dengan begitu log sejak boot saat ini tidak ikut hilang. Cara ini juga menghindari restart systemd-journald. Di versi systemd yang lebih lama, restart journald bisa memutus koneksi stdout/stderr layanan yang sedang berjalan ke journal. Setelah itu ulangi pengecekan dari bagian sebelumnya. ls -l /var/log/journal/ seharusnya sudah menampilkan subfolder machine-id, dan journalctl --disk-usage seharusnya menunjukkan angka dari file di disk. Kalau server kamu sengaja ingin tetap memakai rsyslog berdampingan dengan journald, langkah ini tetap aman. Persistent journal dan rsyslog tidak saling mengganggu. Konsekuensinya hanya log tersimpan dua kali di disk.

Verifikasi setelah reboot dengan journalctl --list-boots

Konfigurasi yang terlihat benar belum tentu bertahan setelah reboot. Satu-satunya bukti yang meyakinkan adalah reboot sungguhan. Lakukan di jam yang aman. Kalau server itu melayani produksi, jadwalkan seperti maintenance biasa. Setelah server naik lagi:

BASH

journalctl --list-boots

# Contoh format output (bukan dari server nyata):
#  -1 0a1b2c3d...  Mon 2026-01-05 10:00:00 WIB  Mon 2026-01-05 22:15:00 WIB
#   0 4e5f6a7b...  Mon 2026-01-05 22:16:30 WIB  Mon 2026-01-05 22:30:00 WIB

# Lihat 50 baris terakhir dari boot sebelumnya
journalctl -b -1 -n 50 --no-pager

# Pastikan flush ke /var berjalan lancar saat boot
systemctl status systemd-journal-flush.service --no-pager

Yang kamu cari adalah minimal dua baris di --list-boots: indeks -1 untuk boot sebelumnya dan 0 untuk boot sekarang. journalctl -b -1 seharusnya menampilkan baris-baris terakhir sebelum server mati, termasuk pesan shutdown kalau reboot-nya normal. Kalau server mati mendadak, misalnya karena kernel panic atau host VPS bermasalah, bagian paling akhir bisa terpotong. Itu wajar karena data yang belum sempat ditulis ke disk memang hilang. systemd-journal-flush.service adalah unit yang memindahkan journal dari /run ke /var/log/journal saat boot, setelah /var siap dipakai. Kalau statusnya gagal, cek dulu bagian berikutnya.

Hal yang sering bikin setting tidak jalan

Beberapa penyebab yang biasanya muncul kalau --list-boots masih menampilkan satu baris setelah reboot:

Drop-in lain menimpa nilai kamu. File drop-in dibaca berurutan berdasarkan nama, dan nilai dari file terakhir yang menang. Kalau ada file lain dengan nama yang urutannya lebih belakang dan berisi Storage=volatile, setting kamu kalah. Jalankan lagi systemd-analyze cat-config systemd/journald.conf dan lihat semua baris Storage.
/var atau /var/log ada di partisi terpisah yang gagal mount atau mount-nya terlambat. Cek dengan findmnt /var/log dan baca log systemd-journal-flush.service.
Disk penuh atau inode habis. journald akan berhenti menulis ke disk kalau ruangnya tidak cukup. Cek dengan df -h /var/log dan df -i /var/log.
Server berupa container (misalnya LXC) atau image minimal yang sengaja mengatur journal volatile. Di lingkungan seperti ini, keputusan simpan atau tidaknya kadang ada di level host. Cek ke pengelola host sebelum mengubah apa pun.
VM hasil clone memakai /etc/machine-id yang sama dengan VM sumbernya. Persistent journal tetap jalan, tapi kalau beberapa journal dikumpulkan ke satu tempat, data dari VM yang berbeda bisa tercampur karena memakai ID yang sama.

Satu catatan soal ukuran. Begitu persistent, journal akan memakan disk. journald punya batas default lewat SystemMaxUse=, biasanya berupa persentase dari ukuran filesystem dengan batas atas tertentu. Nilai persisnya tergantung versi, jadi cek man journald.conf di server kamu. Di VPS dengan disk kecil, sebaiknya tetapkan batasnya secara eksplisit di drop-in yang sama, misalnya SystemMaxUse=500M sebagai contoh angka. Pantau hasilnya dengan journalctl --disk-usage. Intinya, setelah pindah dari rsyslog jangan anggap log otomatis aman di disk. Cek tiga hal: nilai Storage yang efektif lewat systemd-analyze cat-config, keberadaan folder /var/log/journal dengan permission yang benar, dan yang paling penting, journalctl --list-boots setelah reboot sungguhan. Kalau boot sebelumnya muncul di daftar itu, kamu tidak akan kehilangan jejak saat server berikutnya restart tanpa sebab yang jelas.