systemd-journald: Failed to write entry: No space left on device Linux / DevOps

Ошибка systemd-journald: Failed to write entry: No space left on device

Обновлено: 18.08.2026 · Официальная база знаний

Демон логирования перестает записывать новые системные события на диск. В аварийном выводе ядра появляется: systemd-journald: Failed to write entry: No space left on device или write to /var/log/journal failed.

Точка отказа	Параметр ограничения	Последствия
Корневой раздел `/var/log`	100% Disk Usage (df -h)	Блокировка сервисов, сбой ротации логов
Таблица Inodes	100% Inodes (df -i)	Невозможность создания новых .journal файлов
Буфер памяти journald	`Storage=persistent`	Логи переходят в аварийный режим хранения в RAM

Проверьте свободное место на диске и занятость inode:
```
df -h /var/log
df -i /var/log
```
Выполните принудительную ротацию и очистку журнала:
```
sudo journalctl --rotate
sudo journalctl --vacuum-time=2d
sudo journalctl --vacuum-size=500M
```

Ограничьте предельный размер хранилища в /etc/systemd/journald.conf:

sudo nano /etc/systemd/journald.conf

[Journal]
Storage=persistent
SystemMaxUse=1G
SystemKeepFree=2G
RuntimeMaxUse=200M
MaxRetentionSec=1month

Перезапустите демон журналов:
```
sudo systemctl restart systemd-journald
```

Важно: Если диск забит не журналами, проверьте временные каталоги /tmp и /var/tmp, а также удаленные открытые дескрипторы через lsof +L1.

Практический опыт инженера: Не устанавливайте SystemMaxUse в процентах на серверах с терабайтными дисками — 10% по умолчанию на диске 2 ТБ займут 200 ГБ логов.

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

Безопасно ли удалять файлы из /var/log/journal/ вручную?

Рекомендуется использовать команду journalctl --vacuum-size, но при критическом сбое можно удалить старые .journal файлы и перезапустить systemd-journald.

Что произойдет с логами, если диск переполнен?

systemd-journald временно переключается на хранение логов в кольцевом буфере оперативной памяти (/run/log/journal).