Как мне остановить эту постоянную потерю свободного места?

Я работал под управлением Ubuntu, как обычно, когда неожиданно у меня появилось диалоговое окно, в котором говорилось, что у меня осталось всего 1,2 ГБ свободного места. За час до этого у меня было 30 ГБ свободного места.

Я удалил кое-что и увеличил свободное место до 25 ГБ. Но это продолжает уменьшаться. Я пытался удалить старые файлы журналов и усекать файлы журналов и тому подобное, и это продолжает уменьшаться!

Я пытался с помощью Disk Analyzer определить, откуда взялась вся эта потеря свободного места, и это не сработало, так как показал все как положено. Я перезагрузился, и в итоге Ubuntu проверил диск, который каким-то образом вернул свободное пространство до 40 ГБ, но все равно продолжает уменьшаться примерно на 10 ГБ в день. Я продолжаю пытаться найти новые способы освобождения места, но это похоже на автоматизированный процесс уменьшения дискового пространства, который я не могу остановить.

Я не знаю, что делать. Как я могу найти причину и остановить уменьшение свободного места?

Вот результат из sudo du -sh /var/* ~/.xsession-errors:

13M /var/backups
204M    /var/cache
112M    /var/crash
4.0K    /var/games
503M    /var/lib
4.0K    /var/local
0       /var/lock
9.5G    /var/log
85M     /var/mail
4.0K    /var/metrics
24K     /var/opt
0       /var/run
1.7M    /var/spool
391M    /var/tmp
11G     /var/tvmobili
20K     /var/www
224K    /home/school/.xsession-errors
15
задан 4 April 2013 в 06:18

3 ответа

эта проблема была решена, это был брандмауэр, пишущий тонны журналов и файлы кодирования твмобили

0
ответ дан 4 April 2013 в 06:18

У вас есть несколько неконтролируемых журналов. Вместо того, чтобы удалять, как сумасшедшие, каждый день, найдите быстро растущий файл или файлы и загляните внутрь , чтобы выяснить, что может быть причиной этого. Возможно, какая-то программа вращается в цикле, регистрируя некоторые условия. Либо отключите эту программу, отключите ее ведение журнала или попробуйте исправить условие, на которое она жалуется.

Если файл растет на ваших глазах, и вы не знаете, какая программа пишет в него, вы можете легко это выяснить. Вот пример. Кто открыл /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 раза без проверки, что больше, чем одно- или двузначный максимум.

0
ответ дан 4 April 2013 в 06:18

Дисковая проверка освободила часть пространства, предположив, что эта проблема (или часть его) может произойти из-за повреждения файловой системы. Если это так, затем необходимо смочь освободить больше пространства путем сканирования и восстановления файловой системы. Однако, если повреждение постоянно происходит (который мог бы или не мог бы иметь место), который обычно означает, что жесткий диск умирает. Если бы Ваши резервные копии (Ваших документов и каких-либо других важных файлов, которые было бы трудно заменить) не абсолютно актуальны, создайте резервную копию всего важного теперь!

Чтобы проверить и восстановить диск, это не может быть смонтировано (по крайней мере, не чтение-запись). Таким образом, необходимо выполнить утилиту восстановления от продуктивной среды (живой CD/DVD или USB). Во-первых, необходимо будет узнать имя устройства раздела, который содержит файлы.

Поэтому в установленной системе, выполненной:

mount | grep ' on / '

(Удостоверьтесь, что включали пространство между / и '.)

Вы получите что-то как:

/dev/sda8 on / type ext4 (rw,errors=remount-ro)

Текст прежде on- в примере от моей машины, /dev/sda8- полное имя устройства для Вашего корневого раздела (/). Запишите это - Вам будет нужен он.

Затем загрузите свой компьютер от рабочего стола Ubuntu CD/DVD или карта флэш-памяти с интерфейсом USB, как то, что Вы раньше устанавливали Ubuntu первоначально. (Если это - система Wubi, установленная с установщиком Windows, сообщите нам. Я не ожидаю, что, учитывая то, о чем Вы сообщили, но если это так, процедура будет отличаться.)

Избранная Попытка Ubuntu, не устанавливая (не Установка Ubuntu). Когда Вы получите функционирующий рабочий стол, нажмите Ctrl+Alt+T для открытия Окна терминала. Затем выполните эту команду:

sudo e2fsck -fkccp /dev/sda8

Но удостоверьтесь, что заменили /dev/sda8 с правильным полным именем устройства для Вашего / раздел, когда Вы получили через метод, подробно изложенный выше.

Это может требовать времени. c опции, включенные в ту команду, заставляют это сканировать поверхность диска для ошибок, а также файловой системы (и отметить любые плохие области как плохие, таким образом, они не используются). Можно уехать cc если Вам нравится (если Вы делаете, можно также не учесть k), но я рекомендую удержать их.

Вам можно предложить о решении определенных проблем, если e2fsck думает, что существует значительная вероятность, что попытка зафиксировать их могла вызвать потерю данных. ( p делает его так, чтобы это решило любые проблемы, что уверено, что это может зафиксировать, не вызывая сложности.)

Я рекомендую, чтобы Вы были сильно склонны позволить этому фиксировать независимо от того, что это хочет, так как необходимо только делать это после проверки, что резервные копии являются текущими, так или иначе. Если Вы хотите, чтобы это делало попытку даже потенциально опасных мер, не предлагая Вам, замените p с y.

После этого начальная загрузка назад в Вашу систему Ubuntu и видит, освобождено ли пространство. Если это не, или если проблема продолжается, прокомментируйте и отредактируйте свой вопрос предоставить подробную информацию.

3
ответ дан 4 April 2013 в 06:18

Другие вопросы по тегам:

Похожие вопросы: