В Linux можно удалить файл, но продолжать читать из него или записывать в него данные!

Если процесс уже открыл файл, его можно удалить из каталога:

exec {LOG}>/tmp/debug.log
rm /tmp/debug.log

Имя /tmp/debug.log исчезнет, и открыть файл по этому пути уже нельзя. Но Bash продолжает держать открытый файловый дескриптор, поэтому запись работает:

printf '%s\n' "debug message" >&"$LOG"

Причина в семантике Unix: rm удаляет имя файла из каталога через unlink(), а открытый файловый дескриптор продолжает ссылаться на тот же объект файловой системы.

Пока дескриптор открыт, занятое файлом место также не освобождается. Это объясняет распространённую ситуацию, когда огромный лог уже удалили, ls его не показывает, а свободного места на диске не прибавилось.

Закрываем последний дескриптор:

exec {LOG}>&-

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

Именно поэтому при расследовании занятого диска стоит искать не только большие файлы, но и уже удалённые файлы, которые продолжают удерживать работающие процессы.

🔥 В Linux имя файла и открытый файл — не одно и то же. Понимание этой особенности помогает находить утечки дискового пространства и аккуратно работать с временными данными.

🚪 Linux Ready | #совет

Знали, что systemd умеет запускать сервис автоматически при изменении файла?

Многие используют cron или пишут циклы с проверкой времени изменения:

while true; do
  check_file
  sleep 10
done

Но systemd уже имеет встроенный механизм наблюдения за файлами через .path units.

Например, можно следить за конфигурацией:

[Path]
PathChanged=/etc/myapp/config.yml
Unit=myapp-reload.service

Теперь при изменении файла systemd автоматически запустит нужный сервис.

Проверить активные path-наблюдатели:

systemctl list-paths

Запуск и остановка работают так же, как у обычных unit:

systemctl enable --now myapp.path
systemctl stop myapp.path

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

🔥 systemd.path заменяет самописные циклы с sleep и проверки файлов. Вместо опроса система реагирует только тогда, когда изменение действительно произошло.

🚪 Linux Ready | #совет

Как umask определяет права файлов!

Почему новый файл обычно получает 644, каталог — 755, а один и тот же сервис при разных способах запуска может создавать их с другими правами? За этим стоит umask — маска, которая ограничивает разрешения в момент создания объекта.

umask
umask -S

umask не задаёт итоговые права напрямую. При обычном создании программы часто запрашивают 0666 для файлов и 0777 для каталогов, а маска исключает из запрошенного режима запрещённые биты.

Для чистоты эксперимента удалим объекты, если они остались от предыдущего запуска:

rm -f example.txt
rm -rf example_dir

umask 022

touch example.txt
mkdir example_dir

stat -c '%A %a %n' example.txt example_dir

При 022 запись запрещена для группы и остальных, поэтому получаем 644 для файла и 755 для каталога:

-rw-r--r-- 644 example.txt
drwxr-xr-x 755 example_dir

Популярное объяснение 666 - 022 = 644 удобно для некоторых масок, но технически неверно. Здесь работает побитовая маска:

0666 & ~0022 = 0644
0777 & ~0022 = 0755

И это важно не только теоретически. Например, арифметика ломается уже здесь:

rm -f example.txt

umask 033
touch example.txt

stat -c '%A %a %n' example.txt

Получим:

-rw-r--r-- 644 example.txt

Хотя арифметическое 666 - 033 дало бы 633.

umask может только убрать права, которые запросил процесс, но не добавить отсутствующие. Поэтому даже нулевая маска не сделает обычный файл исполняемым:

rm -f test

umask 000
touch test

stat -c '%A %a %n' test

touch создаёт файл без execute-битов, поэтому результат — 666, а не 777:

-rw-rw-rw- 666 test

Для серверных процессов часто используют более строгий 027: владелец сохраняет запрошенные права, у группы убирается запись, а для остальных запрещаются все права.

rm -f config.txt
rm -rf private_dir

umask 027

touch config.txt
mkdir private_dir

stat -c '%A %a %n' config.txt private_dir

Получаем:

-rw-r----- 640 config.txt
drwxr-x--- 750 private_dir

umask — свойство процесса и наследуется дочерними процессами. Поэтому маска вашего интерактивного shell и процесса, запущенного через systemd, может различаться.

Посмотреть настройку сервиса:

systemctl show nginx -p UMask

Для systemd-сервиса маску можно явно зафиксировать:

[Service]
User=www-data
UMask=0027
ExecStart=/usr/bin/example

После изменения unit-файла перечитываем конфигурацию и перезапускаем сервис:

systemctl daemon-reload
systemctl restart example.service

Но есть нюанс, из-за которого даже при ожидаемом umask можно получить другие права — default ACL родительского каталога.

Если у родительского каталога задан default ACL, при создании объекта umask не используется для обычного расчёта mode & ~umask. Вместо этого новый объект наследует default ACL, а унаследованные разрешения ограничиваются правами, которые запросил создающий процесс.

Проверить ACL:

getfacl /path/to/parent

Поэтому, если сервис создаёт файл не с теми правами, проверять нужно не только значение umask. Важны также mode, который запрашивает сама программа, реальная маска процесса, способ его запуска — shell, systemd, контейнер — и наличие default ACL у родительского каталога. Для диагностики:

umask
getfacl .
stat -c '%A %a %n' example.txt

🔥 umask не назначает права — он ограничивает разрешения, которые процесс запросил при создании объекта. А при наличии default ACL в расчёт вступает механизм наследования ACL.

🚪 Linux Ready | #практика

📂 Напоминалка про переадресацию портов (Port Forwarding)!

Port Forwarding позволяет принимать соединение на одном адресе и порту и перенаправлять трафик на другой — например, с 127.0.0.1:8080 на 172.17.0.3:80.

На картинке показано, чем отличается обычное прямое соединение от переадресации портов, а также два основных подхода: через отдельный процесс в user space и средствами сетевого стека ядра в kernel space.

Сохрани, чтобы не потерять!

🚪 Linux Ready | #ресурс

GNU mv умеет атомарно менять два файла или каталога местами!

Обычно при переключении релиза делают несколько переименований: текущий каталог убирают в сторону, новый ставят на его место. Между этими операциями существует промежуточное состояние.

У mv теперь есть --exchange:

mv -T --exchange release-new release-current

Если оба пути находятся в одной файловой системе и она поддерживает атомарный обмен, mv меняет их местами одной операцией: release-current становится новым релизом, а прежнее содержимое оказывается в release-new.

Причём это не только для каталогов:

mv --exchange config.new config.conf

Поменять их обратно можно той же командой:

mv --exchange config.new config.conf

Для сценариев, где нельзя допустить незаметного перехода к копированию между файловыми системами, можно добавить --no-copy:

mv -T --exchange --no-copy release-new release-current

🔥 mv --exchange — случай, когда обычная Unix-команда даёт удобный интерфейс к атомарной операции файловой системы, что полезно для переключения релизов, деревьев сборки и быстрого отката без цепочки промежуточных переименований.

🚪 Linux Ready | #совет

📂 Напоминалка для работы с Linux cgroup v2!

Например, cpu.max позволяет ограничить процессам доступное CPU-время, а memory.max — установить жёсткий лимит на использование оперативной памяти.

На картинке — устройство иерархии cgroup v2, основные контроллеры, системные файлы и команды для создания групп, ограничения ресурсов и перемещения процессов.

Сохрани, чтобы не потерять!

🚪 Linux Ready | #ресурс

🐱 RU Awesome DevOps — большая русскоязычная подборка материалов для DevOps и SRE-инженеров!

Здесь собрана документация по Linux, администрированию серверов, сетям и безопасности, Docker, Kubernetes, Ansible, Terraform, CI/CD, мониторингу, облачным платформам и базам данных. Отдельно есть книги, материалы по алгоритмам и вопросы для подготовки к техническим собеседованиям.

Оставляю ссылочку: GitHub 📱

🚪 Linux Ready | #репозиторий