Linux / DevOps

Закончилось место на Linux сервере: поиск тяжелых логов (du) и безопасная очистка (truncate)

Обновлено: 27.08.2026 · Официальная документация ↗

Критическая ошибка: No space left on device

Когда свободное дисковое пространство на сервере с CRM-системой (Битрикс24, 1С, WordPress) опускается до 0%, сервер переходит в аварийный режим: базы данных MySQL падают, сайты перестают открываться, а сессии пользователей сбрасываются.

Симптомы 100% переполнения диска:

Где проявляется	Текст ошибки	Причина
Консоль терминала	«-bash: cannot create temp file for here-document: No space left on device».	Операционная система не может создать даже временный файл дескриптора в `/tmp`.
База данных MySQL / MariaDB	«[ERROR] Disk full (/var/tmp/...); waiting for someone to free some space...».	Таблицы InnoDB заблокированы на запись для предотвращения повреждения данных.
Команда `df -h`	Раздел `/dev/vda1` смонтирован в `/` со значением Use% = 100%.	Диск переполнен гигантскими файлами журналов (error.log) или бэкапами.

Пошаговый алгоритм поиска и очистки диска

Шаг 1. Оцениваем занятое пространство и находим виновника:
Выполните команду анализа размера папок в корневом каталоге:
```
# Показывает размер папок первого уровня:
sudo du -ahx --max-depth=1 / | sort -rh | head -n 15
```
Обычно виновниками являются папки /var/log (разросшиеся логи), /var/lib/docker (кэш контейнеров) или /tmp.

Шаг 2. Поиск топ-10 самых гигантских файлов на всем диске:

sudo find / -xdev -type f -size +100M -exec ls -lh {} + | awk '{ print $5 " " $9 }' | sort -rh | head -n 10

Шаг 3. ПРАВИЛЬНАЯ очистка работающего лог-файла через truncate:
Критическая ошибка новичков: Никогда не удаляйте активный лог командой rm -f file.log! Служба (Nginx/MySQL) продолжит держать дескриптор открытым, и место на диске НЕ освободится до перезагрузки сервера. Используйте truncate!
```
# Безопасное обнуление размера файла до 0 байт на лету:
sudo truncate -s 0 /var/log/nginx/error.log
sudo truncate -s 0 /var/log/syslog
sudo truncate -s 0 /var/log/journal/*/*.journal
```

Шаг 4. Очистка системного журнала systemd journald:

Ограничьте размер журнала последних дней и очистите старый мусор:

# Удалить журналы старше 2 дней:
sudo journalctl --vacuum-time=2d

# Ограничить максимальный размер логов 200 Мегабайтами:
sudo journalctl --vacuum-size=200M

Шаг 5. Очистка кэша менеджера пакетов APT:
```
sudo apt clean
sudo apt autoremove --purge -y
```

Проверка освободившегося места: Выполните df -h. Значение Avail должно показать свободные гигабайты, после чего перезапустите упавшие базы данных: sudo systemctl restart mysql.

💡 Практика специалистов: Всегда используйте команду `truncate -s 0 file.log` или конструкцию `: > file.log` для очистки активных файлов журналов. Это мгновенно освобождает дисковое пространство без остановки сервисов и поломки файловых дескрипторов Linux.

Частые вопросы (FAQ)

Почему я удалил файл через rm, но команда df -h все равно показывает 100% занятости?

Файл был заблокирован работающим процессом. Найдите такие 'удаленные невидимки' командой `sudo lsof +L1` и перезапустите соответствующий процесс (например, `systemctl restart nginx`).

Как настроить, чтобы логи автоматически сжимались и не забивали диск?

За автоматическую ротацию и сжатие старых логов отвечает системная утилита **Logrotate** (настройки хранятся в файле `/etc/logrotate.conf` и папке `/etc/logrotate.d/`).

Что делать, если место на диске есть (df -h показывает 50%), но система пишет 'No space left'?

Закончились свободные дескрипторы файлов (иноды). Проверьте команду `df -i`. Если `IUse% = 100%`, значит диск забит миллионами мелких файлов (кэш PHP сессий в `/var/lib/php/sessions`).

Безопасно ли очищать папку /tmp вручную?

Да, временные файлы можно очистить командой `sudo rm -rf /tmp/*`, но нельзя удалять саму директорию `/tmp`.