Що робити, якщо у каталозі /var закінчилося місце

На відміну від звичного стилю статей у нашому блозі, ця стаття написана у форматі короткого конкретного посібника, оскільки порушене в ній питання вирішується конкретними діями й не вимагає довгих роздумів про історію питання та його філософію, як ми це любимо :)

Ми лише підкреслимо, що цей посібник розрахований насамперед на користувачів Debian та Ubuntu. Звісно, команди діагностики df, du, find та lsof підходять і для більшості інших Linux-систем, але ось команди apt актуальні для Debian-подібних дистрибутивів, а робота з journalctl - для систем із systemd.

Отже, перше, з чого варто почати, якщо ви отримали повідомлення No space left on device - НЕ починайте одразу видаляти файли з /var. Для початку потрібно провести невелике розслідування та з’ясувати, що саме зайняло вільне місце на цьому розділі.

1. Перевіряємо вільний простір

Насамперед перевіряємо фактичне заповнення розділу, щоб виключити помилкові повідомлення:

df -h /var

Якщо Use%близький до 100%, то файлова система дійсно заповнена.

Заодно перевіримо inode:

df -i /var

і якщо IUse% досяг 100%, то проблема в кількості файлів. Таке трапляється при наявності мільйонів дрібних файлів сеансів, кешу або тимчасових файлів.

2. Знаходимо найбільший каталог

sudo du -xhd1 /var | sort -h

Наприклад:

120M    /var/cache
380M    /var/log
1.1G    /var/www
18G     /var/lib
20G     /var

У цьому випадку ми переходимо до /var/lib і повторюємо команду для знайденого великого каталогу:

sudo du -xhd1 /var/lib | sort -h

Окремі файли розміром понад 500 МБ можна знайти так:

sudo find /var -xdev -type f -size +500M -exec ls -lh {} \;

3. Якщо розрослися каталоги /var/log

Перевіряємо розміри:

sudo du -h --max-depth=1 /var/log | sort -h

Шукаємо найбільші логи:

sudo find /var/log -type f -printf “%s %p\n” | sort -n | tail -20

Активний лог краще обнулити, а не видаляти, оскільки не всі сервіси можуть створювати логи самостійно, і це може призвести до збою деяких сервісів:

sudo truncate -s 0 /var/log/example.log

Після цього перевірте причину зростання конкретного логу, а також перевірте налаштування logrotate - ну або налаштуйте його, якщо ще цього не зробили. Якщо ж програма знову записує гігабайти помилок, то очевидно, що вільного місця незабаром знову швидко не вистачить.

4. Перевіряємо журнал systemd

Розмір журналу:

sudo journalctl --disk-usage

Видалити записи, старші за 14 днів:

sudo journalctl --vacuum-time=14d

Або обмежити поточний обсяг:

sudo journalctl --rotate

sudo journalctl --vacuum-size=500M

Постійний ліміт можна задати в конфігурації journald у файлі /etc/systemd/journald.conf:

[Journal]

SystemMaxUse=500M

5. Якщо місце зайняв Docker

Спочатку перевіряємо:

docker system df

Якщо потрібно детальніше:

docker system df -v

Видалити стандартний набір невикористовуваних об'єктів:

docker system prune

!Не видаляйте вміст /var/lib/docker/overlay2 вручну.

З docker system prune -a і особливо --volumes теж будьте обережні, оскільки Docker може вважати том невикористовуваним, хоча всередині залишилися потрібні дані.

6. Очищаємо кеш APT

Перевіряємо:

sudo du -sh /var/cache/apt

І очищаємо завантажені пакети:

sudo apt clean

Також можна перевірити непотрібні залежності:

sudo apt autoremove

Перед підтвердженням autoremove прочитайте список пакетів, які будуть видалені.

7. Якщо /var/lib займає багато місця

Перевіряємо:

sudo du -xhd1 /var/lib | sort -h

Тут будьте обережні. У /var/libзнаходяться робочі дані Docker, PostgreSQL, MySQL/MariaDB та інших сервісів.

Увага! Ніколи не виконуйте повне очищення цього каталогу!

Якщо багато місця займає /var/lib/mysql або /var/lib/postgresql, то шукайте причину за допомогою самої СУБД. Файли діючої бази даних не видаляйте вручну.

8. df і du показують різні розміри

Видалений файл може й надалі займати місце на диску, якщо його тримає відкритим активний процес.

Перевіряємо:

sudo lsof +L1

Якщо там виявився великий видалений лог, знайдіть процес, що його утримує, і коректно перезапустіть відповідний сервіс. Після закриття файлового дескриптора місце звільниться.

9. Перевіряємо результат

df -h /var

df -i /var

Перевіряємо сервіси, що вишли з ладу:

systemctl --failed

По суті, схема діагностики виявляється досить простою:

Ну а якщо вам знадобиться Linux VPS для тестів або розгортання власного проєкту, то ви знаєте, куди звернутися.