26 March 2026 12:30
truncate - команда, которая меняет размер файла. Можно сделать файл меньше, можно больше (дополнив нулями). Чаще всего её используют, чтобы быстро очистить лог, который занял всё место, но при этом не останавливать сервис, который в этот лог пишет.
Простой синтаксис:
truncate -s 0 /путь/к/файлу
`-s` - размер, `0` - сделать файл пустым.
Можно указывать размер в мегабайтах, гигабайтах и т.д.:
- `truncate -s 10M файл` - обрезать до 10 мегабайт (если больше - лишнее отрежется, если меньше - дополнится нулями)
- `truncate -s -5M файл` - уменьшить на 5 мегабайт от текущего размера
- `truncate -s +5M файл` - увеличить на 5 мегабайт
Когда это реально выручает
1. Логи Docker-контейнера раздулись до десятков гигабайт
Docker пишет вывод контейнера в один файл (`*-json.log`), и если не ограничить ротацию, этот файл может стать огромным. Место на диске закончилось, а контейнер остановить нельзя. `rm` в этом случае не освободит место - процесс Docker держит файл открытым, и данные останутся на диске до перезапуска контейнера. А `truncate -s 0` обнуляет файл, место освобождается сразу, контейнер продолжает работать и пишет логи дальше с чистого листа.
2. Логи приложений, которые долго работают и не перезапускаются
То же самое с nginx, postgres, любым сервисом, который пишет в файл и держит его открытым. Можно удалить файл (`rm`), но место не освободится, пока процесс не закроет дескриптор (обычно при перезапуске). `truncate` позволяет очистить содержимое, не трогая дескриптор, - и место становится свободным мгновенно.
3. Быстро освободить место, но оставить файл для будущего использования
Например, временный файл или файл подкачки. Если он больше не нужен сейчас, но может понадобиться позже, можно обнулить его, а когда понадобится - увеличить обратно (например, `truncate -s 2G`). Это быстрее, чем удалять и создавать заново.
4. Подготовка файлов для тестов
`truncate` может создать файл нужного размера практически мгновенно (sparse file), не записывая реальные данные. Удобно для эмуляции дисков, тестирования скриптов, монтирования образов.
Почему `rm` не всегда подходит
Когда процесс открыл файл и пишет в него, `rm` удаляет только имя файла. Сам файл (его данные) продолжает существовать, пока процесс не закроет его. Место на диске не освобождается. Файл становится невидимым в `ls`, но по‑прежнему занимает место. Увидеть такие «висячие» файлы можно через `lsof | grep deleted`.
Освободить место после `rm` можно только перезапустив процесс (или дождавшись, когда он сам закроет файл). В случае с Docker перезапустить контейнер или демон. Это не всегда удобно, особенно если сервис критичный.
`truncate` же работает с самим файлом, не трогая его имя, и освобождает место немедленно.
Есть ли подводные камни
- Не все процессы корректно реагируют на `truncate`. Если процесс запоминает позицию записи в файле (offset), то после обнуления файла он может продолжить писать не с начала, а с той же позиции, создавая «дырку». В результате файл будет выглядеть пустым в начале, а данные пойдут с какого-то смещения, и место может не освободиться полностью. С логами такое случается редко, но если приложение специфическое, лучше проверить.
- `truncate` не удаляет файл, он остаётся в файловой системе. Если нужно освободить не только данные, но и inode (например, если файлов слишком много), то после остановки процесса всё равно придётся сделать `rm`.
- Данные после `truncate` восстановить нельзя. Даже если процесс ещё ничего не писал в файл, блоки данных уже помечены как свободные и могут быть перезаписаны. В отличие от `rm`, когда файл удалён, но процесс держит его открытым, данные можно вытащить через `/proc/<pid>/fd/*`. После `truncate` такой возможности нет - данные освобождаются сразу.
Что с восстановлением после `truncate`
Если случайно обнулил не тот файл - шансов практически нет. Операционная система освобождает блоки данных, и они быстро перезаписываются. В теории можно попытаться восстановить что-то через `debugfs` или `extundelete`, но на практике для больших файлов это сложно и редко приводит к успеху. Так что перед `truncate` стоит убедиться, что файл действительно можно очищать.
Итог
`truncate` - простая и мощная команда, которая выручает, когда нужно быстро освободить место, не останавливая работающие процессы. Особенно полезна в администрировании Docker-контейнеров и сервисов с долгоживущими логами. Но лучше всё-таки настраивать ротацию логов заранее (logrotate, ограничения Docker), чтобы не приходилось чистить гигантские файлы вручную.
Если есть возможность - сначала посмотри, что в файле, убедись, что он не нужен, и только потом обнуляй. И помни: после `truncate` назад дороги нет.
PS: Материал подготовил Харьков Валентин.