Debian/Ubuntu: как исправить sudo: no space left on device из-за /tmp, /var/tmp и journald

Ошибка sudo: no space left on device в Debian и Ubuntu выглядит как банальное переполнение диска, но на практике причин несколько. Часто забивается не весь сервер, а конкретная точка монтирования: /tmp, /var/tmp, /var/log/journal или отдельный tmpfs. Иногда заканчиваются не гигабайты, а inode, и тогда свободное место по df -h ещё есть, а файлы уже не создаются.

Особенно неприятно, когда ошибка всплывает именно через sudo. Утилита пытается создать временные файлы, обратиться к журналу или задействовать плагины, которым нужен доступ к временным каталогам. Если /tmp или /var/tmp переполнены, если у них неверные права или если журнал systemd разросся до предела файловой системы, симптом будет один: система не может записать ещё один файл.

Ниже — практический runbook для серверов и виртуальных машин. Он подойдёт и для обычной VPS, и для production-инстанса. Если вы держите проекты на VDS, такой чек-лист полезно иметь под рукой как аварийную инструкцию.

Главная мысль: сначала выясняем, что именно закончилось — блоки, inode, место в tmpfs или объём журнала, и только потом чистим.

С чего начать: быстрая диагностика за 2–3 минуты

Первый этап — понять, какая файловая система заполнена и нет ли проблем именно с временными каталогами.

df -h

df -i

mount | egrep ' /tmp | /var/tmp | /var/log '

ls -ld /tmp /var/tmp

findmnt /tmp

journalctl --disk-usage

Что смотреть в выводе:

• df -h показывает, где закончились блоки диска.
• df -i показывает, не закончились ли inode.
• ls -ld /tmp /var/tmp должен показывать права drwxrwxrwt, то есть режим 1777.
• findmnt /tmp помогает понять, является ли /tmp отдельным tmpfs.
• journalctl --disk-usage показывает, сколько места занял журнал systemd.

Если сервер отвечает медленно или вы уже подозреваете, что проблема в логах, сразу проверьте крупные каталоги:

du -sh /var/log/* 2>/dev/null | sort -h

du -sh /var/log/journal 2>/dev/null

du -sh /tmp /var/tmp 2>/dev/null

Очень частый сценарий: корневой раздел / почти заполнен, а основной вклад дают /var/log/journal, старые архивы в /var/tmp или зависшие временные файлы сборки и обновлений в /tmp.

Почему ошибка проявляется именно через sudo

Фраза sudo: no space left on device не означает, что виноват сам sudo. Это лишь первая утилита, которая столкнулась с невозможностью записи. Причины обычно такие:

• переполнен корневой раздел или отдельный раздел /var;
• переполнен tmpfs, смонтированный на /tmp;
• закончились inode на файловой системе;
• каталог /tmp имеет неверные права;
• journald занял слишком много места в /var/log/journal;
• на диске есть удалённые, но всё ещё открытые процессами файлы.

Последний пункт особенно коварен: вы удалили большой лог, но процесс всё ещё держит файловый дескриптор, и реальное место не освободилось. В таком случае du показывает одно, а df — другое.

Если у вас активно используется systemd-журнал, пригодится и отдельный разбор про настройку и работу с systemd journal: он помогает лучше понимать, откуда берётся внезапный рост логов.

Проверки на этом этапе уже достаточно, чтобы понять направление: искать большие файлы, чистить временные каталоги, разбираться с журналом или смотреть в сторону inode и открытых удалённых файлов.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Проверяем /tmp и /var/tmp

Каталоги /tmp и /var/tmp похожи по назначению, но используются немного по-разному. В /tmp обычно лежат краткоживущие временные файлы. В /var/tmp часто хранятся более долгоживущие данные: кэши установщиков, архивы, результаты сборки, временные файлы приложений.

Для начала посмотрите, кто занимает место:

du -xhd1 /tmp 2>/dev/null | sort -h

du -xhd1 /var/tmp 2>/dev/null | sort -h

find /tmp -mindepth 1 -maxdepth 1 -printf '%TY-%Tm-%Td %TT %s %p\n' 2>/dev/null | sort

find /var/tmp -mindepth 1 -maxdepth 1 -printf '%TY-%Tm-%Td %TT %s %p\n' 2>/dev/null | sort

Если видите очевидный мусор — старые архивы, дампы, временные директории сборок, файлы приложений с датой недельной или месячной давности — лучше чистить адресно. Бездумный rm -rf /tmp/* на рабочей системе легко ломает обновления, деплой или активные фоновые задачи.

Более безопасный подход — удалять только старые файлы:

find /tmp -xdev -type f -mtime +1 -delete

find /var/tmp -xdev -type f -mtime +7 -delete

Если в каталоге есть старые пустые директории, их можно убрать отдельно:

find /tmp -xdev -depth -type d -empty -mtime +1 -delete

find /var/tmp -xdev -depth -type d -empty -mtime +7 -delete

Отдельно проверьте права:

stat -c '%a %A %n' /tmp /var/tmp

Для /tmp и обычно для /var/tmp ожидаем режим 1777. Если права сломаны, это может давать ошибки, очень похожие на нехватку места.

chmod 1777 /tmp /var/tmp

Эту команду применяйте только если вы уверены, что права действительно некорректны.

Если /tmp — это tmpfs, место может закончиться в RAM, а не на диске

Во многих системах /tmp смонтирован как tmpfs. Тогда каталог использует оперативную память и swap, а его размер ограничен параметрами монтирования. В результате проблема может быть не в диске вообще.

Проверьте тип и размер:

findmnt -no TARGET,SOURCE,FSTYPE,OPTIONS /tmp

df -h /tmp

free -h

Если /tmp — это tmpfs на 512M или 1G, а у вас там временно работает распаковка пакетов, сборка проекта, обработка архивов или загрузка больших файлов, лимит закончится очень быстро.

• очистите содержимое /tmp;
• временно перенесите операцию в другой каталог;
• увеличьте размер tmpfs, если хватает RAM и swap.

Временно перемонтировать /tmp с большим лимитом можно так:

mount -o remount,size=1G /tmp

Постоянная настройка через /etc/fstab может выглядеть так:

tmpfs /tmp tmpfs defaults,nosuid,nodev,size=1G 0 0

Если у вас веб-стек активно пишет временные файлы, посмотрите также материал про временные каталоги Nginx, tmpfs и I/O — там как раз разбираются типичные сценарии, когда место уходит не туда, куда ожидаешь.

Как проверить и очистить journald

Systemd-journald — один из самых частых источников неожиданно заполненного /var. На активных серверах журнал может разрастись из-за многословных сервисов, циклов рестарта, ошибок приложений и отладочного логирования.

Сначала оцените объём:

journalctl --disk-usage

du -sh /var/log/journal 2>/dev/null

du -xhd1 /var/log/journal 2>/dev/null | sort -h

Если журнал действительно занял слишком много, используйте штатную очистку:

journalctl --vacuum-size=200M

journalctl --vacuum-time=7d

journalctl --rotate

journalctl --vacuum-size=200M

Практически это означает следующее:

• --vacuum-size ограничивает общий размер журналов;
• --vacuum-time удаляет записи старше заданного периода;
• --rotate принудительно завершает текущий файл журнала, после чего очистка работает точнее.

Если места совсем мало, полезно сначала выполнить --rotate, а затем --vacuum-size. Так освобождение происходит предсказуемее.

Чтобы проблема не повторялась, задайте лимиты в конфигурации journald:

grep -E '^(SystemMaxUse|SystemKeepFree|RuntimeMaxUse|RuntimeKeepFree)' /etc/systemd/journald.conf /etc/systemd/journald.conf.d/*.conf 2>/dev/null

Пример разумной настройки для небольшого сервера:

[Journal]
SystemMaxUse=300M
SystemKeepFree=200M
RuntimeMaxUse=100M
RuntimeKeepFree=100M

После изменения конфигурации перезапустите сервис:

systemctl restart systemd-journald

Подбирайте значения под объём диска. На маленькой машине без лимитов журнал легко съедает критическую долю раздела /var или корня.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Когда виноваты не гигабайты, а inode

Ещё один классический случай для no space left on device — это исчерпание inode. То есть место в байтах ещё есть, но файлов на разделе уже слишком много. Такое часто бывает при миллионах мелких файлов: кэшах, временных объектах, очередях, распаковках зависимостей.

Проверка простая:

df -i

for d in / /tmp /var /var/tmp /var/log; do echo "== $d =="; find "$d" -xdev -printf '.' 2>/dev/null | wc -c; done

Если по df -i занято 100% inode, ищите каталоги с огромным числом мелких файлов. Обычно это:

• кэши приложений;
• спул-каталоги;
• временные директории распаковки;
• логи, нарезанные на множество файлов;
• битые пайплайны, которые создают миллионы пустых файлов.

Быстро найти подозрительные места можно так:

find /var/tmp -xdev -type f | sed 's#/[^/]*$##' | sort | uniq -c | sort -n | tail

find /tmp -xdev -type f | sed 's#/[^/]*$##' | sort | uniq -c | sort -n | tail

Лечится это не увеличением журнала или swap, а удалением массивов мелких файлов и поиском источника их генерации.

Проверьте удалённые, но ещё занятые файлы

Если после очистки du показывает, что место освободилось, а df — что нет, вероятно, есть удалённые файлы, которые всё ещё открыты процессами. Это типичная история с логами.

lsof +L1

В выводе ищите большие файлы с пометкой (deleted). Пока процесс держит дескриптор, блоки не вернутся файловой системе. Решение — корректно перезапустить соответствующий сервис.

systemctl restart nginx

systemctl restart php8.2-fpm

systemctl restart mysql

Перезапускайте только тот сервис, который действительно держит удалённый файл, и обязательно оценивайте влияние на production.

Безопасный порядок действий, если место закончилось прямо сейчас

Когда сервер уже в аварийном состоянии, важна последовательность. Вот рабочий алгоритм, который снижает риск сделать хуже:

1. Проверьте df -h и df -i.
2. Оцените /tmp, /var/tmp и /var/log/journal.
3. Освободите немного места адресной очисткой старых временных файлов.
4. Выполните journalctl --rotate, затем journalctl --vacuum-size=....
5. Проверьте lsof +L1 на удалённые открытые файлы.
6. Только после этого переходите к более широкой уборке логов, кэшей и пакетов.

Пример минимального аварийного набора команд:

df -h

df -i

du -sh /tmp /var/tmp /var/log/journal 2>/dev/null

find /tmp -xdev -type f -mtime +1 -delete

find /var/tmp -xdev -type f -mtime +7 -delete

journalctl --rotate

journalctl --vacuum-size=200M

lsof +L1

Этого обычно достаточно, чтобы вернуть системе возможность создавать временные файлы и снова пользоваться административными командами без сбоев.

Как сделать так, чтобы проблема не повторялась

Разовая очистка помогает только в момент инцидента. Чтобы ошибка не вернулась через неделю, нужна профилактика.

Ограничьте journald

Если журнал не лимитировать, он рано или поздно упрётся в диск. Для небольших серверов лучше сразу задать понятный предел в /etc/systemd/journald.conf.

Проверьте политику очистки tmp

В Debian и Ubuntu за временные файлы часто отвечает systemd-tmpfiles. Полезно посмотреть действующие правила:

systemd-tmpfiles --cat-config | sed -n '/tmp/p;/var\/tmp/p'

Если приложение складирует мусор в нестандартный каталог, лучше добавить отдельное правило очистки, а не надеяться, что всё исчезнет само.

Следите за крупными логами и циклами рестарта

Если сервис пишет десятки гигабайт логов, корень проблемы не в journald, а в самом приложении. Частая причина — падение воркера в цикле, слишком подробный debug-режим или нештатный поток ошибок.

Контролируйте размер tmpfs

Слишком маленький /tmp в формате tmpfs опасен для задач с крупными временными файлами. Слишком большой — опасен уже для памяти. Значение должно соответствовать реальной нагрузке.

Настройте мониторинг

Минимальный набор метрик:

• заполнение файловых систем в процентах;
• свободные inode;
• размер /var/log/journal;
• заполнение /tmp, если это tmpfs;
• аномальный рост числа файлов в /tmp и /var/tmp.

Если сервер регулярно упирается в диск, а на нём уже живут логи, база, веб-сервер и фоновые задачи, проблема может быть не в очистке, а в нехватке ресурсов. В таком случае иногда проще вовремя перейти на более ёмкий VDS или пересмотреть размещение сервисов.

Чего делать не стоит

В аварийной ситуации соблазн почистить всё подряд очень велик, но именно так чаще всего ломают рабочую систему.

• Не удаляйте вслепую всё содержимое /tmp и /var/tmp на production.
• Не трогайте руками бинарные журнальные файлы в /var/log/journal, если можно использовать journalctl --vacuum-*.
• Не путайте нехватку блоков и нехватку inode.
• Не считайте, что раз du мало показывает, значит место точно есть — проверьте lsof +L1.
• Не увеличивайте tmpfs без понимания, хватит ли памяти.

Самый безопасный способ борьбы с переполнением — сначала локализовать виновника, затем освобождать место штатными механизмами конкретной подсистемы.

Короткий итог

Если вы столкнулись с sudo: no space left on device в Debian или Ubuntu, начните с трёх проверок: df -h, df -i и journalctl --disk-usage. Затем разберите состояние /tmp и /var/tmp, проверьте, не является ли /tmp маленьким tmpfs, и посмотрите, нет ли удалённых, но открытых файлов через lsof +L1.

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