Anda mendapat beberapa log yang tidak terkontrol. Alih-alih menghapus seperti orang gila setiap hari, temukan file atau file yang tumbuh cepat, dan lihat ke dalam untuk menyelidiki apa yang menyebabkan ini. Mungkin beberapa program berputar dalam satu lingkaran, mencatat beberapa syarat. Baik menonaktifkan program itu, menonaktifkan logging-nya atau mencoba untuk memperbaiki kondisi yang dikeluhkannya.
Jika sebuah file tumbuh di depan mata Anda, dan Anda tidak tahu program mana yang menulisnya, Anda mungkin dapat menemukannya dengan mudah. Berikut ini sebuah contoh. Siapa yang /var/log/syslogmembuka? Kami menggunakan fuserperintah:
# fuser /var/log/syslog
/var/log/syslog: 602
Hanya satu proses yang /var/log/syslogterbuka. Ini adalah proses 602. Apa itu? Mari kita tidak repot-repot dengan psdan grep, tetapi lihat /procfilesystem secara langsung:
# ls -l /proc/602/exe
lrwxrwxrwx 1 root root 0 Mar 29 17:45 /proc/602/exe -> /usr/sbin/rsyslogd
Aha, benar rsyslogd. Kami tidak terkejut karena rsyslogdtelah /var/log/syslog/terbuka.
Metode ini tidak dijamin berfungsi. Alasannya adalah bahwa program tidak harus membuat file tetap terbuka untuk menulis kepada mereka. Misalkan Anda memiliki proses yang membuka file, menambahkannya, dan kemudian menutupnya. Anda akan memiliki penyelidikan yang agak lebih sulit. Anda bisa menjalankan fuserberkali-kali sampai kebetulan Anda menangkap proses "tangan merah". Proses itu sendiri bisa masuk dan keluar dari keberadaan dengan cepat. Masalah lain adalah beberapa proses dapat membuat file terbuka, tetapi hanya satu yang membuatnya lebih besar. Dalam hal ini, Anda dapat melacak panggilan sistem mereka.
# fuser /var/log/huge-annoying-file
/var/log/huge-annoying-file: 1234 23459
Ups! Dua proses membuatnya terbuka: 1234 dan 23459. Mari kita lihat apa yang mereka lakukan:
# strace -p 1234
Process 1234 attached - interrupt to quit
select(1, NULL, NULL, NULL, {9, 922666}
Itu tidak melakukan apa-apa, hanya memblokir selectpanggilan. Ctrl-C untuk menghentikan jejak:
select(1, NULL, NULL, NULL, {9, 922666}^C <unfinished ...>
Periksa yang berikutnya:
# strace -p 23459
write(5, "Useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
^C
Ups, yang itu terus-menerus menulis. Itu pasti yang buruk. Kita bahkan dapat memeriksa bahwa deskriptor file 5 yang menjadi proses penulisan sebenarnya adalah file besar:
# ls -l /proc/23459/fd/5
lr-x------ 1 root root 64 Apr 3 23:39 /proc/23459/fd/5 -> /var/log/huge-annoying-file
Saya tidak curiga Anda memiliki sistem file yang rusak, tetapi untuk memaksakan pemeriksaan penuh, Anda tidak harus boot DVD.
Pertama, tinjau pengaturan jumlah maksimum pemasangan sistem file Anda. Identifikasi partisi Anda menggunakan perintah df. Contoh pada sistem Ubuntu yang saya miliki di sini:
# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 18062108 5499320 11645284 33% /
udev 392152 4 392148 1% /dev
tmpfs 159768 768 159000 1% /run
none 5120 0 5120 0% /run/lock
none 399416 200 399216 1% /run/shm
/dev/sr0 43668 43668 0 100% /media/VBOXADDITIONS_4.1.4_74291
Anda dapat melihat bahwa sistem /file sudah terpasang /dev/sda1. Begitu /dev/sda1juga perangkat penyimpanan partisi root (dan satu-satunya partisi dalam sistem khusus ini).
Mari kita lihat beberapa atribut dari sistem file itu. Ini aman untuk dilakukan meskipun sudah terpasang. Perintah memuntahkan banyak output. Berikut ini kutipannya:
$ dumpe2fs /dev/sda1
dumpe2fs 1.42 (29-Nov-2011)
Filesystem volume name: <none>
Last mounted on: /
[ ... SNIP ... ]
Last mount time: Fri Mar 29 17:45:18 2013
Last write time: Tue Mar 5 09:08:03 2013
Mount count: 22
Maximum mount count: 22
[ ... SNIP ... ]
Hei lihat, jumlah pemasangan sama dengan jumlah pemasangan maksimum. Lain kali saya reboot, akan ada pemeriksaan sistem file. Yang penting adalah bahwa hitungan mount adalah nilai positif. Jika milik Anda nol, ubah ke beberapa nilai positif seperti 22 gunakan tune2fs -c 22 /dev/whatever. Nol berarti bahwa pemeriksaan tidak pernah dipaksakan terlepas dari berapa kali partisi tersebut dipasang. Sistem yang jarang dinyalakan ulang harus memiliki nilai rendah di sini. Sebuah server yang turun setahun sekali mungkin bisa menggunakan fsck setiap kali reboot. Anda dapat mengatur interval pemeriksaan berbasis tanggal juga.
Sekarang untuk memaksa cek, Anda dapat mengganti jumlah aktual menjadi lebih besar atau sama dengan maksimum, dan kemudian reboot. Itu dilakukan dengan modal C: tune2fs -C 1234 /dev/whatever. Sekarang partisi sepertinya telah dipasang 1234 kali tanpa cek, yang lebih besar dari maksimum satu atau dua digit.
sudo du -sh /var/* ~/.xsession-errorstolong? (dua tempat yang saya harapkan akan meledak jika ada sesuatu yang konyol). Kalau tidak, saya dengan Eliah - ini menunjukkan masalah disk. Ambil ini dengan serius.