incron в Linux: мониторинг файлов и автоматизация без cron-расписания

incron – это «cron для inotify»: команды запускаются не по расписанию, а когда в файловой системе происходит событие (создание, правка, удаление, перемещение). Для админов и DevOps это удобный способ реагировать на загрузки, правки конфигов и появление артефактов без постоянного polling.

Что умеет incron

Под капотом – подсистема inotify в ядре Linux. Служба incrond читает правила (incrontab) и на каждое совпадение маски событий запускает указанную команду. Типичные возможности:

• реакция на create/modify/delete/move в каталогах и на отдельных файлах;
• отдельные правила на разные пути;
• подстановка пути и имени файла в команду ($@, $#);
• логирование срабатываний для отладки.

Сценарии: обработка загрузок в upload-каталог, алерты при правке nginx.conf, запуск конвертации медиа, триггер бэкапа при появлении новых данных.

Установка

Debian / Ubuntu

sudo apt-get update
sudo apt-get install incron
sudo systemctl status incron
sudo systemctl enable --now incron

Имя unit-файла в Debian-семействе часто incron; если status «not found», проверьте incrond.service.

RHEL / CentOS / Alma / Rocky

# CentOS 7 и аналоги
sudo yum install incron

# более новые релизы
sudo dnf install incron

sudo systemctl enable --now incrond
sudo systemctl status incrond

Fedora

sudo dnf install incron
sudo systemctl enable --now incrond

Arch Linux

sudo pacman -Sy incron
sudo systemctl enable --now incrond

Кто может пользоваться incrontab

Как и с cron, доступ часто режется allow/deny-файлами (типичные пути: /etc/incron.allow, /etc/incron.deny). Если incrontab -e отказывает обычному пользователю – добавьте логин в allow или работайте от root осознанно. Системные правила иногда кладут в /etc/incron.d/ (зависит от пакета и дистрибутива).

Формат правил

Редактор таблицы:

incrontab -e
# список правил текущего пользователя
incrontab -l

Строка правила:

<путь_к_файлу_или_каталогу> <маска_событий> <команда>

Частые маски: IN_CREATE, IN_MODIFY, IN_DELETE, IN_MOVED_TO, IN_MOVED_FROM, IN_ATTRIB, IN_CLOSE_WRITE. Несколько событий можно перечислить через запятую. Плейсхолдеры:

• $@ – путь из правила (каталог или файл);
• $# – имя объекта события (для каталога – имя файла);
• $% / $& – числовой и текстовый код события (смотрите man incrontab).

Примеры

Обработка новых загрузок

При появлении файла в /var/www/uploads запускается скрипт; полный путь собирается из каталога и имени:

/var/www/uploads IN_CREATE /usr/local/bin/process_new_file.sh $@/$#

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

Алерт при правке конфига

/etc/nginx/nginx.conf IN_MODIFY /usr/local/bin/notify_nginx_change.sh

Внутри скрипта – mail, webhook в мессенджер, запись в журнал. Длинные пайпы прямо в incrontab неудобны (экранирование, shell); отдельный скрипт проще сопровождать.

Реакция на удаление

/var/cache/myapp/tmp IN_DELETE /usr/local/bin/on_tmp_delete.sh $@/$#

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

Сценарии в духе DevOps

• Локальный CI-триггер – появление артефакта или checkout в каталоге запускает сборку/тесты (для «настоящего» CI лучше webhooks VCS, но на edge-хосте incron бывает уместен).
• Логи и алерты – реакция на ротацию или появление error-маркера (для high-volume логов чаще filebeat/vector, не incron).
• Контроль целостности конфигов – мгновенный сигнал о правке критичных файлов (дополняет, но не заменяет auditd/AIDE).
• Бэкапы по событию – старт копирования, когда в каталог данных легли новые файлы.
• Медиа-конвейер – конвертация/сжатие сразу после загрузки.

Практика и ограничения

• Логи – смотрите journald (journalctl -u incrond / -u incron) и системный syslog; без логов отладка масок мучительна.
• Права – incrond запускает команду от владельца таблицы; скрипт должен иметь execute и доступ к путям. Не раздавайте world-writable на скрипты из incrontab.
• Рекурсия – классический inotify/incron не всегда удобен для глубокого дерева «из коробки»; для рекурсивного watch часто берут другие инструменты или явные правила на нужные уровни.
• Лимиты ядра – fs.inotify.max_user_watches и соседние sysctl; при большом числе путей watch’и заканчиваются.
• Не дублируйте systemd – если задача «когда появился путь, запусти unit», посмотрите systemd.path. Для аудита безопасности – auditd. Для расписания – cron.

Типичные ошибки

1. Служба не запущена – пакет поставили, unit не enable/start.
2. Пользователь не в allow – incrontab -e молча или явно отказывает.
3. Неверная маска – ждали «файл полностью записан», повесили только IN_CREATE.
4. Права на каталог – нет доступа на watch или на чтение нового файла.
5. Сломанное экранирование – пробелы в именах, спецсимволы shell; передавайте путь аргументом в скрипт в кавычках внутри скрипта, а не через хрупкую one-liner команду.
6. Шторм событий – правило на шумный каталог без debounce в скрипте.

Краткий итог

incron хорошо закрывает нишу «файл изменился – сразу скрипт» на Linux-хостах: upload-пайпы, алерты по конфигам, простая автоматизация без тяжёлого агента. Ставьте пакет, включите unit, ограничьте доступ через allow, пишите короткие идемпотентные скрипты и не тащите в incrontab то, что лучше решает systemd.path, auditd или нормальный CI.

Источники и ссылки