Какова причина того, что корень на 100%?
У меня есть 5-летний ноутбук Ubuntu. Он работает 12,04 LTS и никогда не доставлял мне особых проблем. Прошлой ночью во время обновления выскочил дисковый анализатор и сказал, что у меня осталось очень мало места. Это было правильно.
С тех пор я вручную очищаю старые ядра и связанные с ними файлы в / boot. Я снизился с 95% до 89%. Я посмотрел в / var / spool и почистил много, но не очень больших файлов спула, которые никогда не печатались давным-давно. Дисковый анализатор просто указывает на root на 100%, показывая / usr на 45%, и остальное для всего остального, включая /home.
Я проверил с помощью Synaptic. У меня не установлены большие пакеты, такие как apache или mysql. Что еще может быть заполнением диска и как мне подойти к очистке, отличной от установки методом грубой силы?
Я использую этот скрипт
#!/bin/bash
ORPHANS=`deborphan`
if [ ! -z "$ORPHANS" ]; then
dpkg --remove $ORPHANS
fi
PURGES=`dpkg --list | grep ^rc | awk '{ print $2; }'`
if [ ! -z "$PURGES" ]; then
dpkg --purge $PURGES
fi
, который я нашел здесь .
Однако, это только пустило корни до 88%, и добавление deborphan добавило 1%, когда мне пришлось его устанавливать.
2 ответа
Если у Вас есть несколько разделов, сначала не потрудитесь чистить не полные разделы. Внимание на то, которое полно.
Вы можете df -h /some/dir, чтобы проверить, полон ли раздел, содержащий/some/dir, или не (конечно, мог бы быть еще один раздел, смонтированный внизу.. если так, примите его во внимание)
, можно также искать крупнейших директоров путем сортировки размера каждого dirextory: как корень, сделайте df -kS / | sort -n и быть терпеливыми... (поскольку виду нужен целый вывод перед сортировкой, Вы будете видеть все после того как концы du) (du -kS отличаются от du -ks: это не считает subdirs, таким образом, это помогает точно определить точный dir, содержащий большие файлы. Работы с гну du, по крайней мере.)
Иначе: как корень, find -type f -size +100000 -ls | sort -k7,7n для нахождения самых больших файлов, только производя самое большое (больше чем 512x100000=51 МБ) (поскольку аргумент размера находится в 512 байтах (размер блока по умолчанию)). Номер 7 в виде должен отсортировать на 7-м поле. Корректируйтесь, если размер находится в другом поле (я делаю это из памяти, я путешествую...) (-k7,7n, говорит вид виду численно "от 7-го до 7-го поля" как othrrwise поля сортировки вида, 7-е к последнему, которое не могло обычно быть тем, что Вы хотите...)
Наиболее вероятное место для изучения /var/log/. Я помню время, когда logrotate не был настроен для обработки всех соответствующих файлов журнала.
Начинают с du -sh /var/log/* видеть, существует ли "огромный" каталог там.