Думаете такого не бывает? Еще как бывает, особенно в Linux.
Cannot create temporary directory /tmp/: No space left on device (28)
Именно такое или похожее сообщение иногда можно встретить на высоконагруженных серверах, но при этом место на сервере есть
df -h
No space left on device
В Linux это может значить не только про гигабайты, но и про inode'ы или про ограничения на конкретный раздел.
Возможные причины:
Закончились inode’ы
Даже если гигабайты свободны, если inode закончились, система не сможет создать новые файлы (в том числе временные в /tmp).
Проверить можно так:
df -i
1. Если IUse% на / или /tmp = 100% → виноваты inode’ы, как в моем случае (обычно из-за кучи мелких файлов, например, логов или кэша).
2. Ограничения на tmpfs
/tmp может быть смонтирован как tmpfs (в памяти). В выводе df -h нет строки для /tmp, значит он может использоваться по умолчанию через systemd-tmpfiles. Размер tmpfs обычно ограничен частью RAM.
Проверить можно так:
mount | grep /tmp
Если там tmpfs, то он ограничен (например, половина оперативки).
Как лечить No space left on device:
- Если inode закончились:
df -i
# ищем раздел с 100%. Потом ищем, где мусор:
find /var/log -type f | wc -l
find /tmp -type f | wc -l
#Чистим:
rm -rf /tmp/*
journalctl --vacuum-time=7d
- Если /tmp — tmpfs и он мал:
Можно временно перемонтировать с большим размером, например 1G:
mount -o remount,size=1G /tmp
Чтобы сделать это постоянным — правим /etc/fstab или systemd unit для /tmp.
В моем случае inode-ы на корневом разделе закончились.
Поэтому система больше не может создать ни одного нового файла (хоть место в гигах и есть).
Что делать пошагово:
1. Посмотреть, кто сжирает inode-ы:
Обычно лидируют /var/log, /var/lib/docker, /tmp.Для более детального поиска:
find / -xdev -type d -exec sh -c 'echo -n "{}: "; ls -U "{}" | wc -l' \; | sort -n -k2 | tail
2. Если виноват Docker:
Удаляем неиспользуемые контейнеры, образы, volume’ы (будьте осторожны в проде):
docker system prune -af --volumes
Проверяем:
df -i
3. Если виноваты логи или временные файлы:
Чистим /tmp:
rm -rf /tmp/*
Чистим systemd-журналы (оставим неделю):
journalctl --vacuum-time=7d
В моем случае inodes закончились из-за большого количества файлов в одном из каталогов высоконагруженного сайта.
Профилактика:
- Установить мониторинг inode (например, через zabbix или nagios).
- Настроить регулярный docker system prune.
- Если на сервере реально много мелких файлов по задаче → подумать о пересоздании FS с большим количеством inode.