У вас є кілька журналів поза контролем. Замість того, щоб видаляти як божевільні щодня, знайдіть швидко зростаючий файл чи файли та загляньте всередину, щоб дослідити, що може спричинити це. Можливо, якась програма крутиться в циклі, який записує якусь умову. Або вимкніть цю програму, відключіть її реєстрацію або спробуйте виправити умову, на яку вона скаржиться.
Якщо файл зростає перед вашими очима, і ви не маєте уявлення, яка програма пише до нього, ви можете це легко знайти. Ось приклад. Хто /var/log/syslogвідкрив? Ми використовуємо fuserкоманду:
# fuser /var/log/syslog
/var/log/syslog: 602
Лише один процес /var/log/syslogвідкритий. Це процес 602. Що це? Давайте не будемо заважати psі grep, а подивимось /procбезпосередньо на файлову систему:
# ls -l /proc/602/exe
lrwxrwxrwx 1 root root 0 Mar 29 17:45 /proc/602/exe -> /usr/sbin/rsyslogd
Ага, це так rsyslogd. Ми не здивовані , що rsyslogdє /var/log/syslog/відкрита.
Цей метод не гарантовано працює. Причина полягає в тому, що програмам не потрібно тримати файли відкритими для їх запису. Припустимо, у вас є процес, який відкриває файл, додає його та закриває. У вас буде дещо складніше розслідування. Ви можете бігати fuserбагато разів, поки випадково не впіймаєте процес "червоними руками". Цей процес сам по собі міг швидко входити і вибудовуватись. Ще одна проблема полягає в тому, що декілька процесів можуть відкрити файл, але лише один робить його більшим. У цьому випадку ви можете простежити їх системні дзвінки.
# fuser /var/log/huge-annoying-file
/var/log/huge-annoying-file: 1234 23459
На жаль! Відкрито два процеси: 1234 та 23459. Подивимося, що вони роблять:
# strace -p 1234
Process 1234 attached - interrupt to quit
select(1, NULL, NULL, NULL, {9, 922666}
Це нічого не робить, просто блокує selectдзвінок. Ctrl-C для порушення сліду:
select(1, NULL, NULL, NULL, {9, 922666}^C <unfinished ...>
Перевірте наступне:
# 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
На жаль, це пишуть постійно. Він повинен бути поганим. Ми навіть можемо перевірити, що дескриптор файлу 5, до якого пише процес, насправді є великим файлом:
# 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
Я не підозрюю, що у вас є пошкоджена файлова система, але для примусової перевірки вам не потрібно завантажувати DVD.
По-перше, перегляньте параметр максимальної кількості файлів у вашій файловій системі. Визначте свій розділ за допомогою команди df. Приклад для системи Ubuntu у мене тут:
# 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
Ви можете бачити, що /файлова система змонтована /dev/sda1. Так само /dev/sda1є накопичувачем кореневого розділу (і єдиним розділом у цій конкретній системі).
Давайте розглянемо деякі атрибути цієї файлової системи. Це безпечно зробити, навіть якщо він встановлений. Команда показує багато результатів. Ось уривок:
$ 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 ... ]
Привіт, дивіться, кількість кріплення дорівнює максимальній кількості кріплення. Наступного разу, коли я перезавантажуюсь, буде перевірка файлової системи. Важливим є те, що кількість кріплення - це додатне значення. Якщо ваш нуль, змініть його на якесь додатне значення, наприклад, 22 tune2fs -c 22 /dev/whatever. Нуль означає, що перевірка ніколи не примушується незалежно від того, скільки разів встановлений розділ. Рідко перезавантажені системи повинні мати тут низькі значення. Сервер, який виходить з ладу раз на рік, ймовірно, може використовувати fsck щоразу, коли він перезавантажується. Ви також можете встановити інтервали перевірок на основі дати.
Тепер, щоб примусити перевірити, ви можете змінити фактичну кількість, що перевищує максимальну чи рівну, а потім перезавантажити. Це робиться з капіталом C: tune2fs -C 1234 /dev/whatever. Тепер розділ виглядає так, що він був встановлений 1234 рази без перевірки, що більше одно- або двоцифрового максимуму.
sudo du -sh /var/* ~/.xsession-errorsбудь ласка? (ці два місця я б очікував підірвати, якщо щось буде дурним). Інакше я з Елією - це вказує на проблеми з диском. Поставтеся до цього серйозно.