Что-то сожрало все место на жестком диске!!!

Вы такие заходите на сервер, выполняете df -h и видите следующую картину:

/dev/sdb 49G 49G 0G 100% /var/log

Воу-воу, полегче думаете вы. Расчехляем пылесос и начинаем зачистку логов. Для начала следует выснить кто же поднасрал:

cd /var/log && du -hs ./* | grep G

Видим несколько файлов - 13G и 1G. Так. приехали. Уже что-то не так. окейси, вдруг там кто-то в корень логов насрал множеством файлов. ls -lash - ба. да файлов с папками всего ничего. ХММММ думаете вы. Ну, ок, посчитаем:

du -hs ./
20G

Но ведь df показывает 49!!! WTF!? Что это может значить, когда файлы по факту занимают куда меньше чем показывает общая занятость диска. Первая мысль - проверить размер диска и фс. вдруг кто-то что-то подкрутил. А вторая - куда более правильная - место занимают файлы, которых нет. Нет ничего что занимает, значит это и занимает, ага. Это значит, что мы столкнулись с ситуацией, когда файл с диска удалили, но процесс еще держит его открытым. проверим эту теорию:

# lsof | grep "/var/log" | grep deleted
filebeat   2211                root   13r      REG               8,16 32037162645         27 /var/log/haproxy.log.1 (deleted)
filebeat   2211  2212          root   13r      REG               8,16 32037162645         27 /var/log/haproxy.log.1 (deleted)
filebeat   2211  2213          root   13r      REG               8,16 32037162645         27 /var/log/haproxy.log.1 (deleted)

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

З.Ы. Вычитал тут полезный ключик для ncdu\du - ключ -x - который не будет обсчитывать вглубь примонтированные тома. так, например, если у вас смонтировано на /var, /var/log, итп какие-то тома (удаленные или локальные), запустив ncdu -x / вы получите информацию только по корню без смонтированных.

via Админим с Буквой

repost

Read more posts by this author.