Таймер systemd: расписание отдельно от команды

Ночной отчёт удобнее обслуживать, когда команда запуска и её расписание хранятся отдельно. В systemd за это отвечают service и timer: первый выполняет работу, второй запускает её в нужное время. Соберём такую пару в Debian 12 и проверим, что произойдёт, если сервер пропустит очередной запуск.

Описываем разовый запуск

# /etc/systemd/system/report-demo.service
[Unit]
Description=Build demonstration report

[Service]
Type=oneshot
User=report
WorkingDirectory=/srv/reporting
ExecStart=/usr/local/bin/build-report

# /etc/systemd/system/report-demo.timer
[Unit]
Description=Daily demonstration report

[Timer]
OnCalendar=*-*-* 03:15:00
Persistent=true

[Install]
WantedBy=timers.target

Файлы сохраняют отдельно по указанным путям. Учётная запись, рабочий каталог и программа должны существовать. При одинаковой основе имени таймер активирует соответствующую службу. В службе намеренно нет RemainAfterExit: завершившийся разовый процесс должен перестать считаться активным, чтобы следующая активация могла снова выполнить работу. Пользователю report предоставляют только необходимый доступ к данным.

Разбираем поведение расписания

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

sudo systemctl daemon-reload
sudo systemctl start report-demo.service
sudo systemctl enable --now report-demo.timer
systemctl list-timers report-demo.timer

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

Проверяем результат и ограничения

Если служба ещё активна при очередном срабатывании, таймер не создаёт параллельный экземпляр того же юнита. Это полезно знать при длинном отчёте, однако не решает конкуренцию с ручным запуском программы вне systemd. Там может потребоваться собственная блокировка приложения. Проверка должна включать длительное выполнение и повторный запрос запуска на тестовой среде.

Дождитесь обычного срабатывания и откройте готовый отчёт: важны его дата и содержимое, а не только успешный код процесса. Проверьте запуск после простоя и сообщение об ошибке. Рядом с настройкой запишите владельца задачи, часовой пояс и обычную длительность — это пригодится при следующем изменении расписания.

Источники и дальнейшее чтение

• Debian 12: systemd.timer
• Debian 12: systemd.service