Cron не запускается: причины и способы исправления в Linux

Что означает ошибка "cron не запускается"

Проблема проявляется в том, что запланированные задачи (cron jobs) не выполняются в указанное время. Пользователь не видит ожидаемого результата (например, не создался бэкап, не отправилось письмо), а в логах может отсутствовать какая-либо запись от cron или присутствовать сообщение об ошибке. Важно понимать, что cron сам по себе не генерирует явного "кода ошибки" — задача либо выполняется, либо нет, а диагностика проводится через логи и проверку состояния службы.

Причины возникновения

1. Служба cron не запущена. В системах на systemd демон cron (пакет cronie) или crond (в RHEL-совместимых) может быть остановлен или отключён.
2. Неправильный синтаксис в crontab. Ошибка в формате строки расписания (например, * * * * вместо * * * * *) или в команде.
3. Проблемы с путями и переменными окружения. Cron имеет ограниченное окружение. Использование относительных путей или команд, которых нет в PATH по умолчанию (/usr/bin:/bin), приведёт к сбою.
4. Недостаточно прав (permissions). У скрипта, который пытается выполнить cron, или у каталогов в пути нет прав на выполнение (x) или чтение (r) для пользователя, от которого работает задача (часто root или конкретный системный пользователь).
5. Повреждённый пакет cron или конфликт. Редко, но возможно повреждение файлов пакета cron или конфликт с другим планировщиком (например, anacron).

💡 Совет: В 80% случаев проблема кроется в пунктах 2-4. Начинайте диагностику с логов.

Способы решения

Способ 1: Проверка и перезапуск службы cron

Первым делом убедитесь, что основной демон активен.

1. Проверьте статус службы. Для большинства дистрибутивов она называется cron (Debian/Ubuntu) или crond (RHEL/CentOS/Fedora).

   sudo systemctl status cron  # Для Debian/Ubuntu
   # ИЛИ
   sudo systemctl status crond # Для RHEL/CentOS/Fedora
   

2. Если служба не активна (inactive), запустите её:

   sudo systemctl start cron  # или crond
   

3. Включите автозапуск при загрузке, если это необходимо:

   sudo systemctl enable cron
   

4. После этого проверьте, появились ли в логах (journalctl -u cron -f) записи о попытках выполнения задач.

Способ 2: Анализ логов cron

Логи — главный источник истины.

1. Просмотрите системный журнал на предмет сообщений от cron. На Ubuntu/Debian:

   sudo grep CRON /var/log/syslog | tail -20
   

   На RHEL/CentOS/Fedora:

   sudo grep CRON /var/log/cron | tail -20
   

2. Если используется systemd-журнал, команда универсальна:

   sudo journalctl -u cron -b --no-pager | grep -i "error\|fail"
   # Или для crond
   sudo journalctl -u crond -b --no-pager | grep -i "error\|fail"
   

   Флаг -b показывает записи с текущей загрузки. Ищите строки с (username) — это попытки запуска задач. Сообщения BAD FILE MODE или can't open укажут на проблемы с правами.

Способ 3: Проверка и исправление crontab-файла

Ошибки в самом файле расписания — частая причина.

1. Посмотрите текущие задания пользователя (замените username на нужного или используйте sudo crontab -l для root):

   sudo crontab -l -u username
   

2. Проверьте синтаксис. Каждая строка должна иметь 5 полей времени (миниute, hour, day of month, month, day of week) и затем команду. Пример корректной строки:

   * * * * * /usr/bin/python3 /home/user/script.py >> /home/user/log.txt 2>&1
   

   Убедитесь, что используется полный абсолютный путь к исполняемому файлу (/usr/bin/python3, а не просто python3).
3. Проверьте файл скрипта. Убедитесь, что в первой строке указан корректный интерпретатор (shebang), например #!/bin/bash или #!/usr/bin/env python3, и что этот путь существует.
4. Убедитесь в отсутствии пустых строк или комментариев без #. Пустая строка в crontab может вызвать ошибку парсинга у некоторых версий cron.
5. После исправления сохраните файл. Cron автоматически перечитает конфигурацию.

Способ 4: Проверка и исправление прав доступа (Permissions)

Cron запускает задачи от имени конкретного пользователя. У этого пользователя должны быть права.

1. Проверьте права на сам скрипт:

   ls -l /path/to/your/script.sh
   

   Должно быть минимум -rwxr--r-- (755) для скрипта, который должен выполняться. Владельцем должен быть пользователь, от которого запускается задача, или root.

   sudo chmod 755 /path/to/your/script.sh
   sudo chown username:username /path/to/your/script.sh # если нужно
   

2. Проверьте права на все родительские каталоги в пути к скрипту и к любому файлу, который скрипт пытается прочитать/записать. У каждого каталога в цепочке должен быть бит x (execute/search) для пользователя cron.

   namei -l /path/to/your/script.sh
   

   Команда покажет права на каждый компонент пути. Если где-то стоит --- для группы/остальных, cron не сможет пройти.
3. Если задача работает с файлами в домашней директории (/home/username), убедитесь, что у этой директории права 755 (или хотя бы 711).

Способ 5: Альтернатива — перевод задачи на systemd timer

Если проблема с классическим cron не решается, или вам нужны более продвинутые возможности (точное время, логирование в journal, триггеры по событиям), перенесите задачу в systemd timer.

1. Создайте сервисный файл (например, /etc/systemd/system/mybackup.service):

   [Unit]
   Description=My Daily Backup
   
   [Service]
   Type=oneshot
   ExecStart=/usr/local/bin/backup-script.sh
   User=backupuser
   

2. Создайте файл таймера (/etc/systemd/system/mybackup.timer):

   [Unit]
   Description=Run backup daily at 2 AM
   
   [Timer]
   OnCalendar=daily
   Persistent=true
   
   [Install]
   WantedBy=timers.target
   

3. Включите и запустите таймер:

   sudo systemctl daemon-reload
   sudo systemctl enable --now mybackup.timer
   

4. Проверьте статус: sudo systemctl status mybackup.timer.

Способ 6: Переустановка пакета cron (крайняя мера)

Если все вышеперечисленное не помогло, возможно, повреждены бинарные файлы демона.

1. Переустановите пакет cron (Debian/Ubuntu) или cronie (RHEL/CentOS):

   # Debian/Ubuntu
   sudo apt-get update && sudo apt-get install --reinstall cron
   
   # RHEL/CentOS 8+
   sudo dnf reinstall cronie
   

2. После переустановки перезапустите службу (см. Способ 1).

Профилактика

• Всегда используйте абсолютные пути в crontab-строках и внутри скриптов. Для определения полного пути команды используйте which <command>.
• Перенаправляйте вывод (>> /path/to/log 2>&1) даже для простых задач. Это даст invaluable информацию при падении.
• Тестируйте скрипт вручную от имени того пользователя, от которого он будет запускаться cron: sudo -u username /path/to/script.sh.
• Следите за свободным местом на разделе, где находится /var (там могут храниться spool-файлы crontab) и на целевом разделе для логов/бэкапов.
• Рассмотрите переход на systemd timers для новых задач, особенно если они требуют точного времени, зависимостей или расширенного логирования через journalctl.