Logrotate Berhasil, file asli kembali ke ukuran aslinya

Adakah yang punya masalah dengan logrotate sebelum yang menyebabkan file log diputar dan kemudian kembali ke ukuran yang sama seperti aslinya? Inilah temuan saya:

Script Logrotate:

/var/log/mylogfile.log {
    putar 7
    harian
    kompres
    olddir / log_archives
    missingok
    pemberitahuan
    copytruncate
}

Output Verbose dari Logrotate:

menyalin /var/log/mylogfile.log ke /log_archives/mylogfile.log.1
truncating /var/log/mylogfile.log
mengompresi log dengan: / bin / gzip
menghapus log lama /log_archives/mylogfile.log.8.gz

Log file setelah terpotong terjadi

[root @ server ~] # ls -lh /var/log/mylogfile.log
-rw-rw-r-- 1 part1 part1 0 Jan 11 17:32 /var/log/mylogfile.log

Beberapa detik kemudian:

[root @ server ~] # ls -lh /var/log/mylogfile.log
-rw-rw-r-- 1 part1 part1 3.5G 11 Jan 17:32 /var/log/mylogfile.log

Versi RHEL:

[root @ server ~] # cat / etc / redhat-release 
Red Hat Enterprise Linux ES rilis 4 (Pembaruan Nahant 4)

Versi Logrotate:

[root @ DAA21529WWW370 ~] # rpm -qa | grep logrotate
logrotate-3.7.1-10.RHEL4

Beberapa Catatan:

• Layanan tidak dapat dimulai kembali dengan cepat, jadi itu sebabnya saya menggunakan copytruncate
• Log diputar setiap malam, menurut olddirdirektori memiliki file log di dalamnya dari setiap malam.

Ini mungkin karena meskipun Anda memotong file, proses menulis ke file akan terus menulis di mana offset itu pada akhirnya. Jadi yang terjadi adalah logrotate memotong file, ukurannya nol, proses menulis ke file itu lagi, melanjutkan di offset yang ditinggalkannya, dan Anda sekarang memiliki file dengan NULL-byte hingga ke titik di mana Anda memotongnya ditambah yang baru entri yang ditulis ke log.

od -c setelah memotong + pertumbuhan tiba-tiba, menghasilkan output di 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 ini adalah dari offset 0 hingga 33255657600 file Anda terdiri dari null byte, dan kemudian beberapa data yang dapat dibaca. Mendapatkan ke status ini tidak memerlukan jumlah waktu yang sama dengan yang dibutuhkan untuk benar-benar menulis semua null-byte. Filesystem ext {2,3,4} mendukung sesuatu yang disebut file jarang, jadi jika Anda mencari melewati wilayah file yang tidak mengandung apa pun, wilayah itu akan dianggap mengandung null-byte dan tidak akan memakan ruang pada disk. Null byte itu tidak akan benar-benar ditulis, hanya diasumsikan ada di sana, maka waktu yang diperlukan untuk pergi ke 0 hingga 3.5GB tidak memerlukan banyak waktu untuk melakukannya. (Anda dapat menguji jumlah waktu yang diperlukan dengan melakukan sesuatu seperti dd if=${HOME}/.bashrc of=largefile.bin seek=3432343264 bs=1, ini akan menghasilkan file lebih dari 3GB dalam beberapa milidetik).

Jika Anda menjalankan ls -lsfile log setelah dipotong dan mengalami pertumbuhan tiba-tiba lagi, sekarang harus melaporkan angka di awal baris yang mewakili ukuran sebenarnya (dalam blok yang ditempati pada disk), yang mungkin merupakan urutan besarnya lebih kecil dari ukuran yang dilaporkan oleh saja ls -l.

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 untuk menghentikan dan memulai kembali aplikasi Anda ketika log diputar, atau menggunakan alat seperti "rotatelogs" apache, tempat Anda mengumpankan output log ke alat melalui pipa, dan alat tersebut menangani memutar logfile sesering mungkin. Sebagai contoh, salah satu contoh apache saya mencatat

ErrorLog "|/usr/sbin/rotatelogs /www/logs/error_log 604800"

yang menyebabkan banyak file log dengan nama suka

-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 memulai ulang apache; Saya kemudian dapat mengompresnya secara manual setelah fakta. Perhatikan bagaimana rotasi dilakukan setiap minggu, yaitu setiap 604800 detik, itulah argumen yang diteruskan rotatelogs.

Jika Anda tidak bisa berhenti dan memulai ulang aplikasi, dan itu tidak bisa masuk melalui pipa, maka saya pikir Anda punya masalah nyata. Mungkin orang lain akan memiliki saran.

akan sangat bagus jika Anda bisa mengirim seluruh logrotate.

Mengapa mencoba menggunakan kill -HUP? (Reload klasik tidak me-restart ) metode.

Juga ... periksa dengan lsof siapa yang mengakses file.

Cukup gunakan ">>" yang berarti menambahkan bukan ">" yang berarti buat dari skrip Anda yang menulis ke file ini. Saya memiliki masalah yang sama persis dan saya memperbaikinya menggunakan menambahkan dalam skrip saya.

SomeScript.sh >> output.txt

Harapan itu lebih jelas.