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

Я работал под управлением 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

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

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

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

Чтобы проверить и восстановить диск, он не может быть смонтирован (по крайней мере, не для чтения и записи). Поэтому вам следует запустить утилиту восстановления из живого окружения (live CD / DVD или USB). Сначала вам нужно узнать имя устройства раздела, содержащего ваши файлы.

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

mount | grep ' on / '

(Не забудьте указать пробел между /и '.)

Вы получите что-то вроде:

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

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

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

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

sudo e2fsck -fkccp /dev/sda8

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

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

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

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

После этого загрузитесь обратно в систему Ubuntu и посмотрите, освободилось ли место. Если это не так, или если проблема не устранена, прокомментируйте и отредактируйте свой вопрос, чтобы сообщить подробности.

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