Как настроить выполнение задач по расписанию на VPS: cron и systemd timers

В этой статье на примере Ubuntu/Debian разберём:

  • как быстро запускать команды по расписанию через cron;
  • как посмотреть, что задание реально добавилось и выполняется;
  • как настроить systemd timer (аналог cron, но “по-взрослому”);
  • где смотреть логи и что делать, если «не запускается».

Выбираем инструмент: cron или systemd timers

  • cron — лучший выбор, если нужен быстрый результат: “раз в день/раз в час запусти команду”.

  • systemd timers — удобнее, если важны логи, статус, автозапуск после ребута, точность и контроль выполнения.

Практика: для большинства VPS-задач cron хватает с головой. systemd timers стоит использовать там, где нужна надёжность и понятная диагностика.

Вариант 1. Cron: быстро и просто

Cron выполняет команды по расписанию. Расписание задаётся в формате:

* * * * * команда
| | | | |
| | | | └── день недели (0-7)
| | | └──── месяц (1-12)
| | └────── день месяца (1-31)
| └──────── час (0-23)
└────────── минута (0-59)

Проверяем, что cron работает

sudo systemctl status cron

Добавляем задачу через root crontab

Открываем планировщик root:

sudo crontab -e

Пример: ежедневно в 03:15 запускать скрипт:

15 3 * * * /usr/local/bin/vps-health-check.sh >/dev/null 2>&1

Проверяем, что запись сохранилась:

sudo crontab -l
Пример задания в crontab: запуск скрипта по расписанию

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

  • Задание не выполняется — часто из-за путей. В cron лучше указывать полный путь к команде/скрипту и файлам.

  • Скрипт работает вручную, но не работает в cron — потому что в cron другое окружение. Решение: прописывать абсолютные пути и при необходимости задавать переменные окружения в начале.

  • Куда делся вывод? — по умолчанию cron может пытаться слать вывод на почту. Если почта не настроена — это выглядит как “ничего не произошло”. Поэтому или логируйте, или глушите вывод как в примере.

Вариант 2. systemd timers: надёжнее и понятнее

systemd timers — это “cron с админским лицом”: у задачи есть сервис, у сервиса есть статус, а у всего этого есть журнал.

Сделаем пример: ежедневный запуск простого скрипта в 03:15.

1) Создаём сервис

Файл сервиса:

sudo nano /etc/systemd/system/vps-health-check.service

Содержимое:

[Unit]
Description=VPS health check script

[Service]
Type=oneshot
ExecStart=/usr/local/bin/vps-health-check.sh

2) Создаём таймер

Файл таймера:

sudo nano /etc/systemd/system/vps-health-check.timer

Содержимое:

[Unit]
Description=Run VPS health check daily

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

[Install]
WantedBy=timers.target

Что важно:

  • OnCalendar — расписание (каждый день в 03:15).

  • Persistent=true — если сервер был выключен в момент запуска, задача выполнится при следующем старте.

3) Включаем таймер

sudo systemctl daemon-reload
sudo systemctl enable --now vps-health-check.timer

4) Проверяем, что таймер активен

systemctl list-timers --all | grep vps-health-check
Проверка systemd timer через systemctl list-timers

5) Смотрим логи выполнения

sudo journalctl -u vps-health-check.service --since today
Логи выполнения systemd service через journalctl

Что выбрать на практике

  • Cron — если задача простая и вам нужен быстрый результат.

  • systemd timers — если нужна диагностика, журналы, статус и устойчивость к перезагрузкам.

Простой подход: начать с cron. Если задач становится много или нужна отчётность — переносить важные задачи на systemd timers.

Итоги

  • Настроили задачи по расписанию через cron и научились проверять их.

  • Сделали пример systemd timer: сервис + таймер + проверка таймеров.

  • Разобрали типичные причины, почему задания «не запускаются».

Вывод: cron и systemd timers решают одну задачу, но разными способами. Если нужен минимум действий — cron. Если нужен контроль и прозрачность — systemd timers.

Оставить комментарий