Bangun kebijakan logrotate yang terukur, uji tanpa menyentuh konfigurasi sistem, pahami state file serta mekanisme reopen, lalu diagnosis log yang gagal berotasi.
Menyusun aturan size-based dengan retention dan compression, memvalidasinya melalui debug serta state file terpisah, memilih rename/reopen atau copytruncate secara sadar, dan menelusuri kegagalan rotasi berdasarkan bukti.
PersiapanLinux dengan logrotate, shell Bash, dan working directory yang boleh ditulis. Lab memakai file lokal serta state file terpisah; jangan menyalin aturan ke /etc/logrotate.d atau mengirim signal ke service produksi sebelum owner, path, jadwal, dan mekanisme reopen divalidasi.
Log aplikasi yang terus tumbuh dapat memenuhi filesystem, tetapi rotasi yang keliru juga dapat menghilangkan baris, mengubah ownership, atau membuat aplikasi tetap menulis ke file lama. logrotate bukan daemon pemantau ukuran secara real time: aturan baru dievaluasi ketika command dijalankan oleh timer, cron, atau operator. Karena itu konfigurasi, frekuensi eksekusi, state, dan perilaku aplikasi saat file diganti harus dibaca sebagai satu alur.
Gunakan working directory milik user biasa. Lab ini tidak membutuhkan sudo dan sengaja memakai config serta state file lokal. Perintah --force hanya digunakan pada file latihan. Pada server, inventarisasikan path, owner/group, laju pertumbuhan, kebutuhan retention, serta prosedur reopen resmi aplikasi sebelum mengubah konfigurasi sistem.
Tujuannya memastikan command tersedia dan melihat capability build yang digunakan. Output versi dapat berbeda antar-distribusi. Jika command tidak ditemukan, gunakan package manager dan dokumentasi distribusi; jangan mengunduh binary acak.
command -v logrotate
logrotate --versionlogrotate hanya mengevaluasi policy ketika dipanggil. Pada host systemd, cari timer dan status service; distribusi lain mungkin memakai cron. Status inactive pada service oneshot sesudah sukses tidak selalu abnormal—lihat result, exit code, dan waktu eksekusi terakhir.
systemctl list-timers --all 'logrotate*'
systemctl status logrotate.timer --no-pager
systemctl status logrotate.service --no-pager
# Jika timer tidak ada, periksa mekanisme distribusi secara read-only:
ls -l /etc/cron.daily/logrotate /etc/cron.d 2>/dev/nullJika NEXT dan LAST muncul pada list-timers, timer terjadwal dan pernah berjalan. Jika unit tidak ditemukan tetapi script cron tersedia, host mungkin memakai cron. Jika keduanya tidak ada atau disabled, policy tidak akan berjalan otomatis walaupun file konfigurasinya benar; verifikasi package dan standar distribusi sebelum mengaktifkan apa pun.
Direktori berikut menampung active log, arsip, config, dan state. pwd penting karena logrotate membutuhkan path log yang tidak ambigu. Data dibuat lebih besar dari threshold 1 KiB agar keputusan rotasi mudah diamati.
mkdir -p logrotate-lab
cd logrotate-lab
lab_dir=$(pwd)
lab_user=$(id -un)
lab_group=$(id -gn)
dd if=/dev/zero bs=1024 count=2 status=none | tr '\0' 'A' > app.log
printf '\n' >> app.log
stat -c 'size=%s mode=%A owner=%U group=%G path=%n' app.logsize 1k memilih rotasi ketika ukuran melewati threshold saat logrotate dijalankan. rotate 3 menyimpan tiga generasi; compress mengompresi arsip; missingok tidak gagal bila log belum ada; notifempty melewati file kosong; dan create membuat active log baru dengan mode serta identity yang ditentukan. printf memasukkan path, user, dan group aktual sehingga contoh tetap lengkap.
printf '%s\n' \
"$lab_dir/app.log {" \
' size 1k' \
' rotate 3' \
' compress' \
' missingok' \
' notifempty' \
" create 0640 $lab_user $lab_group" \
'}' > app-logrotate.conf
cat app-logrotate.conf--debug mengaktifkan diagnostic output dan tidak mengubah log maupun state. --state menunjuk file lokal agar pengujian tidak membaca atau mengunci state sistem. Cari baris considering log, ukuran/criterion, keputusan needs rotating atau does not need rotating, serta error parsing. Debug sukses belum membuktikan aplikasi akan reopen; ia hanya memvalidasi evaluasi logrotate.
logrotate --debug --state ./logrotate.state ./app-logrotate.confFormat persis bergantung versi. Normal untuk lab adalah config terbaca, app.log dipertimbangkan, dan ukuran memicu rotasi. Error unknown option berarti directive salah; bad rotation count menunjukkan nilai tidak valid; skipping karena permission berarti ownership atau parent directory perlu diperiksa, bukan dibuka dengan chmod 777.
reading config file ./app-logrotate.conf
Reading state from file: ./logrotate.state
considering log /home/alice/logrotate-lab/app.log
log needs rotatingSimpan bukti nama, size, inode, mode, owner, dan group. Inode membantu membedakan active log baru dari file lama yang di-rename. Jangan hanya melihat bahwa file .gz muncul.
stat -c 'inode=%i size=%s mode=%a owner=%U group=%G path=%n' app.log
ls -lah--force mengabaikan keputusan waktu/ukuran sehingga berguna untuk membuktikan alur konfigurasi, tetapi dapat menghasilkan arsip kosong atau mengacaukan retention jika dipakai sembarangan. --verbose memperlihatkan aksi. Karena target dan state berada di lab, command ini tidak menyentuh policy sistem.
logrotate --force --verbose --state ./logrotate.state ./app-logrotate.conf
ls -lah
stat -c 'inode=%i size=%s mode=%a owner=%U group=%G path=%n' app.log
cat logrotate.stateActive app.log seharusnya baru dan kosong dengan mode 640, sedangkan isi lama berada pada app.log.1.gz. Nama dapat berbeda jika policy memakai dateext atau directive global lain. State mencatat waktu evaluasi/rotasi dan dipakai pada keputusan berikutnya.
-rw-r----- app.log
-rw-r--r-- app.log.1.gz
logrotate state -- version 2
"/home/alice/logrotate-lab/app.log" 2026-10-7-3:0:0gzip -t memeriksa integritas stream gzip dan zcat membaca isi ke stdout. wc -c memberi indikasi jumlah byte setelah decompression. Bandingkan dengan size sebelum rotasi; perbedaan tak terduga perlu diselidiki sebelum policy diterapkan.
gzip -t app.log.1.gz
printf 'gzip_test_exit=%s\n' "$?"
zcat app.log.1.gz | wc -cIsi ulang active log lalu lakukan rotasi lab beberapa kali. Dengan rotate 3, hanya tiga generasi terbaru dipertahankan. Ini demonstrasi deterministik, bukan rekomendasi memaksa rotasi berulang di produksi.
for round in 2 3 4; do
dd if=/dev/zero bs=1024 count=2 status=none | tr '\0' "$round" > app.log
printf '\n' >> app.log
logrotate --force --state ./logrotate.state ./app-logrotate.conf
printf 'sesudah_round=%s\n' "$round"
ls -1 app.log*
donesize menjadikan ukuran sebagai criterion utama. maxsize dapat memutar lebih cepat daripada interval waktu yang dipilih, tetapi tetap hanya saat logrotate dipanggil. Contoh: threshold 100 MiB tidak menjamin file berhenti tepat pada 100 MiB bila timer hanya berjalan harian. Selaraskan threshold dengan laju log dan frekuensi scheduler, lalu monitor kapasitas filesystem secara terpisah.
Tanpa copytruncate, logrotate biasanya mengganti nama file lama dan membuat active log baru. Proses yang masih memegang file descriptor lama dapat terus menulis ke inode arsip. Solusi yang disukai adalah aplikasi mendukung log reopen setelah signal atau command resminya. Instruksi signal berbeda untuk setiap service; validasi dokumentasi, unit name, privilege, dan efek signal sebelum menulis postrotate.
Blok postrotate berjalan setelah rotasi dan dapat memanggil mekanisme reopen aplikasi. sharedscripts membuat script dijalankan sekali untuk sekumpulan log. Jangan menebak signal atau me-restart service sebagai template universal. Bentuk berikut sengaja berupa kerangka non-runnable yang harus diganti berdasarkan dokumentasi aplikasi.
/path/to/application.log {
daily
rotate 7
compress
delaycompress
create 0640 appuser appgroup
sharedscripts
postrotate
/absolute/path/to/approved-log-reopen-command
endscript
}copytruncate menyalin isi ke arsip lalu mengosongkan file asli sehingga inode active log tidak berubah. Ini berguna sebagai fallback untuk aplikasi lama yang tidak dapat reopen. Namun ada jeda kecil antara copy dan truncate; baris yang ditulis pada jendela tersebut dapat hilang. Pilih hanya setelah risiko kehilangan log diterima dan mekanisme reopen yang benar-benar didukung tidak tersedia.
delaycompress menunda compression untuk arsip paling baru hingga siklus berikutnya. Ini dapat membantu aplikasi yang masih sesaat menulis ke file hasil rename, tetapi bukan pengganti reopen yang benar. Jika proses terus menulis ke arsip lama tanpa batas, perbaiki lifecycle file descriptor; menunda compression hanya mengurangi gejala.
Jika lsof tersedia dan Anda memiliki izin, cocokkan proses dengan active log dan arsip. Tanda (deleted) menunjukkan proses masih memegang file yang sudah dihapus; ruang disk belum kembali sampai descriptor ditutup. Hasil kosong dapat berarti tidak ada proses membuka file atau akses Anda tidak cukup.
lsof -- "$lab_dir/app.log" "$lab_dir"/app.log.* 2>/dev/null
lsof +L1 2>/dev/null | head -n 20logrotate dapat menolak parent directory yang permission-nya tidak aman. namei -l memperlihatkan owner dan mode setiap komponen path; stat memeriksa target. Jangan mengatasi error dengan chmod 777. Pastikan service account, group, create mode, dan bila diperlukan directive su cocok dengan model ownership yang telah disetujui.
namei -l "$lab_dir/app.log"
stat -c 'mode=%A owner=%U group=%G path=%n' "$lab_dir" "$lab_dir/app.log"Gejala: file membesar tetapi tidak ada arsip. Bukti: jalankan --debug dengan config dan state yang benar, lalu periksa timer/cron serta timestamp state. Interpretasi: does not need rotating dapat berarti threshold belum tercapai, state menganggap rotasi baru terjadi, atau logrotate belum dipanggil lagi. Tindakan berikutnya: cocokkan size, waktu, path, dan frekuensi scheduler; jangan langsung memakai --force di produksi.
Gejala: file sudah dihapus atau diputar tetapi df masih penuh. Bukti: bandingkan df -h, du pada filesystem yang sama, dan lsof +L1. Interpretasi: proses mungkin memegang deleted-open file. Tindakan berikutnya: identifikasi owner proses, gunakan prosedur reload/restart yang disetujui, lalu verifikasi descriptor tertutup dan kapasitas kembali; jangan membunuh proses secara acak.
df -h .
du -sh .
lsof +L1 2>/dev/null | head -n 20Gejala: aplikasi gagal menulis setelah rotasi. Bukti: bandingkan stat sebelum/sesudah, identity service, dan directive create/su. Interpretasi: active log baru mungkin memiliki mode, owner, atau group yang tidak cocok. Tindakan berikutnya: koreksi policy berdasarkan identity sebenarnya, validasi di debug mode, lalu uji satu siklus terkontrol. Jangan memperlebar akses untuk semua user.
Jika policy tidak dievaluasi, periksa timer/cron. Jika dievaluasi tetapi dilewati, periksa criterion dan state. Jika rotasi terjadi tetapi active log tidak ditulis, periksa create ownership dan mekanisme reopen. Jika proses tetap menulis ke arsip, gunakan reopen resmi; pertimbangkan copytruncate hanya sebagai fallback. Jika disk belum lega, cari deleted-open descriptor. Jika arsip terlalu cepat hilang atau terlalu banyak, hitung ulang rotate, interval, compression, laju data, dan kebutuhan investigasi.
Menganggap logrotate memantau file terus-menerus; memakai --force sebagai operasi rutin; menguji langsung di /etc/logrotate.d tanpa state terpisah; menebak signal; memilih copytruncate tanpa menerima loss window; memberi chmod 777; mengabaikan owner/group setelah create; serta hanya memeriksa keberadaan .gz tanpa memastikan aplikasi menulis ke active log baru.
Konfirmasi absolute path, filesystem, owner/group, mode, service identity, dan laju log; tentukan threshold, frekuensi eksekusi, jumlah generasi, compression, serta kebutuhan audit; validasi syntax dengan --debug; gunakan state lab terpisah; uji reopen pada environment aman; periksa inode, active log, arsip, gzip integrity, dan file descriptor; pastikan scheduler aktif; dokumentasikan rollback; lalu monitor disk serta kegagalan job setelah rollout.
Pastikan pwd menunjuk direktori latihan sebelum menghapus file. Perintah berikut hanya menghapus artefak yang dibuat dalam logrotate-lab, bukan konfigurasi sistem.
pwd
rm -f -- app.log app.log.* app-logrotate.conf logrotate.state
cd ..
rmdir logrotate-labPolicy logrotate yang aman bukan sekadar daftar daily, rotate, dan compress. Hasil yang benar bergantung pada kapan policy dievaluasi, apa yang dicatat state file, bagaimana active log dibuat, dan apakah aplikasi membuka ulang file descriptor. Pisahkan validasi syntax, keputusan rotasi, lifecycle aplikasi, retention, serta pemulihan ruang disk agar setiap kegagalan memiliki bukti dan tindakan berikutnya yang jelas.