MAATRIX / Блог / Как установить и настроить cron-задачи на VPS

Как установить и настроить cron-задачи на VPS

Как установить и настроить cron-задачи на VPS

MAATRIX

Резервные копии, отправка отчётов, очистка временных файлов, синхронизация данных — всё это должно происходить само, по расписанию. Cron-задачи на VPS ровно для этого и созданы: планировщик запускает ваши команды в заданное время без вашего участия. Разберём настройку по шагам — синтаксис расписания, редактирование crontab, логирование и типичные грабли, из-за которых задача «не срабатывает».

Обсудить статью, задать вопрос или начать новую тему

Есть вопрос по этой статье, идея для обсуждения или просто хотите поделиться опытом? Сообщество MAATRIX ждёт. Для общения, пожалуйста, зарегистрируйтесь в нашем личном кабинете.

Перейти в сообщество →

Что такое cron и как он устроен

Cron — это системный планировщик задач в Linux, работающий в фоне как демон. Он постоянно сверяется со списком заданий и, когда наступает нужное время, запускает указанную команду. Список заданий у каждого пользователя свой и хранится в так называемом crontab — таблице расписаний. Есть и системные расписания, разложенные по каталогам, но для большинства прикладных задач работают именно с пользовательским crontab.

Каждая строка crontab описывает одно задание: пять полей расписания и команда, которую нужно выполнить. Cron не требует установки в привычном смысле — он входит в состав почти любого дистрибутива и обычно уже запущен. Задача администратора не «поставить cron», а правильно описать расписание и учесть особенности окружения, в котором задание будет исполняться.

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

Шаг 1. Проверка планировщика

На Ubuntu 24.04 cron обычно установлен и работает, но убедиться стоит. Проверьте, что сервис активен, и при необходимости доустановите пакет:

systemctl status cron
apt install -y cron

Если сервис показывает active (running) — планировщик готов. Заодно проверьте часовой пояс сервера: cron ориентируется на системное время, и если пояс не тот, задачи будут срабатывать в неожиданные часы. Посмотреть и при необходимости задать пояс можно так:

timedatectl
timedatectl set-timezone Europe/Moscow

Расхождение часового пояса — частая причина недоумений вида «бэкап запускается не тогда, когда я ждал». Лучше выставить нужный пояс сразу. У MAATRIX сервер выдаётся с root-доступом, так что настроить время и планировщик под себя вы можете с первой минуты.

Нужен сервер под эту задачу?

Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK, США и РФ. Оплата картой РФ и по СБП.

Арендовать VPS

Шаг 2. Синтаксис расписания

Расписание задаётся пятью полями: минута, час, день месяца, месяц, день недели. Каждое поле принимает конкретное значение, диапазон, список или звёздочку, означающую «любое значение». Несколько примеров проясняют логику лучше любой теории:

0 3 * * *      каждый день в 03:00
*/15 * * * *   каждые 15 минут
0 9 * * 1      каждый понедельник в 09:00
30 2 1 * *     первого числа каждого месяца в 02:30

Звёздочка в поле означает «каждый», а запись */N — «каждые N единиц». Освоив эти четыре примера, вы покроете большинство реальных сценариев. Если сомневаетесь в расписании, проговорите его словами: «минута 0, час 3, любой день, любой месяц, любой день недели» — это ежедневный запуск в три ночи. Такая проверка вслух отсекает ошибки в полях.

Шаг 3. Редактирование crontab

Свой список задач вы открываете командой редактирования crontab. Она вызывает редактор с вашей персональной таблицей — править файлы вручную не нужно:

crontab -e

При первом запуске система спросит редактор — выберите привычный. Добавьте строку с расписанием и командой. Ключевое правило, которое экономит часы отладки: всегда указывайте полные, абсолютные пути и к исполняемым файлам, и к скриптам, и к их данным. Из-за урезанного окружения cron может не знать, где лежит нужная программа:

0 3 * * * /usr/bin/python3 /home/user/scripts/backup.py

Просмотреть текущий список задач без редактирования можно командой crontab -l. Она полезна, чтобы убедиться, что задание сохранилось, и держать перед глазами всё расписание пользователя.

Шаг 4. Логирование — обязательный шаг

Главная ловушка новичка — задание вроде бы добавлено, а результата нет, и непонятно, запускалось ли оно вообще. Cron по умолчанию не показывает вывод на экран: он пытается отправить его почтой, которой обычно нет. Поэтому перенаправляйте вывод задачи в лог-файл — и стандартный вывод, и ошибки:

0 3 * * * /home/user/scripts/backup.sh >> /var/log/backup.log 2>&1

Конструкция >> файл 2>&1 дописывает в лог и обычный вывод, и сообщения об ошибках. Теперь, если задача упала, вы увидите причину в логе, а не будете гадать. Это не опциональное украшение, а обязательная практика: без логирования отладка cron превращается в стрельбу вслепую. Заведите привычку логировать каждое задание с самого начала.

Шаг 5. Проверка, что задача реально запускается

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

grep CRON /var/log/syslog | tail

Эти строки показывают, что cron действительно вызвал вашу команду в назначенное время. Если в журнале запуск есть, а результата нет — проблема в самой команде или её окружении, и разбираться нужно по вашему лог-файлу. Если запуска в журнале нет вовсе — дело в расписании или в том, что задание не сохранилось. Такое разделение быстро локализует проблему.

Шаг 6. Надёжность и обслуживание

Cron прост, но пара привычек делает его надёжным. Скрипты, запускаемые по расписанию, пишите так, чтобы они сами задавали нужные переменные окружения и абсолютные пути, а не полагались на окружение интерактивной сессии. Для задач, которые не должны запускаться параллельно (например, тяжёлый бэкап), используйте блокировку через утилиту flock, чтобы новый запуск не стартовал, пока предыдущий не завершился.

Следите за тем, чтобы логи задач не разрастались бесконечно — настройте их ротацию. Периодически просматривайте crontab -l и убирайте задания, которые больше не нужны. Если по расписанию идут тяжёлые операции — обработка данных, сборка отчётов — и они начинают конкурировать за ресурсы, это честный повод перейти на более мощный VPS. Подобрать и оплатить его из России картой, по СБП или криптой удобно у MAATRIX. С логированием, проверкой и аккуратными скриптами cron превращается в незаметного, но надёжного помощника.

Нужен сервер под эту задачу?

Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK, США и РФ. Оплата картой РФ и по СБП.

Арендовать VPS

Обсудить статью, задать вопрос или начать новую тему

Есть вопрос по этой статье, идея для обсуждения или просто хотите поделиться опытом? Сообщество MAATRIX ждёт. Для общения, пожалуйста, зарегистрируйтесь в нашем личном кабинете.

Перейти в сообщество →

Частые вопросы

Почему cron-задача не запускается?

Чаще всего из-за урезанного окружения: команда работает в терминале, но cron не знает путей. Указывайте абсолютные пути и настройте логирование вывода.

Как проверить, что задача отработала?

Перенаправьте вывод в лог-файл конструкцией >> файл 2>&1 и посмотрите факт запуска в системном журнале командой grep CRON /var/log/syslog.

Почему задачи срабатывают не в то время?

Cron ориентируется на часовой пояс сервера. Проверьте его командой timedatectl и при необходимости выставьте нужный пояс.

Как не дать задаче запуститься дважды одновременно?

Оберните команду в блокировку через flock — новый запуск не стартует, пока не завершится предыдущий.

Нужны сами нейросети для контента?

Генерируйте изображения, видео и озвучку нейросетями на falapi.io — десятки моделей в одном окне. Оплата картой РФ и по СБП.