Solusi 1:
Ini mungkin karena meskipun Anda memotong file, proses menulis ke file akan terus menulis pada offset mana pun akhirnya. Jadi yang terjadi adalah logrotate memotong file, ukurannya nol, proses menulis ke file lagi, melanjutkan offset yang ditinggalkannya, dan Anda sekarang memiliki file dengan NULL-byte hingga titik di mana Anda memotongnya ditambah yang baru entri yang ditulis ke log.
od -c setelah truncate + pertumbuhan tiba-tiba, menghasilkan output sepanjang baris:
0000000 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
*
33255657600 \0 C K B - s e r v e r [ h t t
33255657620 <more log output>
Apa yang dikatakan di sini adalah dari offset 0 hingga 33255657600 file Anda terdiri dari byte nol, dan kemudian beberapa data yang dapat dibaca. Mendapatkan ke keadaan ini tidak membutuhkan waktu yang sama untuk benar-benar menulis semua byte nol itu. Sistem file ext{2,3,4} mendukung sesuatu yang disebut file jarang, jadi jika Anda mencari melewati wilayah file yang tidak berisi apa pun, wilayah tersebut akan dianggap berisi null-byte dan tidak akan menghabiskan ruang pada disk. Byte nol itu tidak akan benar-benar ditulis, hanya diasumsikan ada di sana, oleh karena itu waktu yang diperlukan untuk beralih ke 0 hingga 3,5 GB tidak memakan banyak waktu. (Anda dapat menguji jumlah waktu yang dibutuhkan dengan melakukan sesuatu seperti dd if=${HOME}/.bashrc of=largefile.bin seek=3432343264 bs=1 , ini akan menghasilkan file berukuran lebih dari 3 GB dalam beberapa milidetik).
Jika Anda menjalankan ls -ls pada file log Anda setelah dipotong dan tiba-tiba tumbuh lagi, sekarang harus melaporkan angka di awal baris yang mewakili ukuran sebenarnya (dalam blok yang ditempati pada disk), yang mungkin lebih kecil dari ukuran ukuran yang dilaporkan hanya dengan ls -l .
Solusi 2:
Saya sangat yakin bahwa Kjetil telah memukulnya. Drew, Anda mungkin belum yakin dengan penjelasannya, tetapi saya mendorong Anda untuk membaca dengan cermat apa yang dia katakan.
Jika Anda menerimanya, perbaikannya adalah menghentikan dan memulai ulang aplikasi Anda ketika log diputar, atau menggunakan alat seperti "rotatelogs" apache, tempat Anda memasukkan keluaran log ke alat melalui pipa, dan alat tersebut menangani sering memutar file log. Misalnya, salah satu instans apache saya mencatat dengan
ErrorLog "|/usr/sbin/rotatelogs /www/logs/error_log 604800"
yang menyebabkan banyak file log dengan nama seperti
-rw-r--r-- 1 root root 4078 Dec 21 01:04 error_log.1292457600
-rw-r--r-- 1 root root 4472 Dec 29 08:41 error_log.1293062400
-rw-r--r-- 1 root root 78630 Jan 4 12:57 error_log.1293667200
-rw-r--r-- 1 root root 15753 Jan 12 01:10 error_log.1294272000
muncul tanpa me-restart apache; Saya kemudian dapat mengompresnya secara manual setelah fakta. Perhatikan bagaimana rotasi dilakukan setiap minggu, yaitu setiap 604800 detik, yang menjadi argumen diteruskan ke rotatelogs .
Jika Anda tidak dapat menghentikan dan memulai ulang aplikasi, dan aplikasi tidak dapat masuk melalui pipa, maka menurut saya Anda benar-benar mengalami masalah. Mungkin orang lain akan memiliki saran.