Ошибка cron 'bad minute': причины и способы исправления

Что означает ошибка "bad minute"

Ошибка "bad minute" в cron — это синтаксическая ошибка, которая возникает при попытке демона cron прочитать и выполнить задание из файла crontab. Она указывает, что в поле "минуты" расписания указано недопустимое значение.

Полный текст ошибки в логах обычно выглядит так:

(cron) error (bad minute)

или

CRON[12345]: (username) BAD MINUTE (значение)

Контекст появления: Ошибка появляется в системном логе (/var/log/syslog или /var/log/cron) в момент, когда cron пытается запустить задание (обычно в начале каждой минуты). Само задание не будет выполнено до исправления синтаксиса.

Поле "минуты" в формате crontab — это первое из пяти чисел/спецсимволов в строке расписания. Оно должно соответствовать строгим правилам.

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

Ошибка "bad minute" возникает только из-за некорректного значения в первом поле расписания. Конкретные причины:

1. Значение вне диапазона 0-59. Например, 60, 61, -1, 100.
2. Нечисловое значение. Например, sixty, first, * * * * * (если первое поле — *, то это корректно, но если там * * с лишним символом, будет ошибка).
3. Пустое поле или пробел вместо значения. Например, * * * * * (пробел в начале) или * * * * * (если редактор заменил табуляцию).
4. Использование дробного числа. Например, 0.5, 1.5. Допустимы только целые числа.
5. Некорректное сочетание диапазона и шага. Например, 0-60/5 (диапазон выходит за 59) или */0 (деление на ноль).
6. Символы, не являющиеся частью синтаксиса crontab. Например, запятые без чисел, буквы, специальные символы в неположенном месте.

⚠️ Важно: Поле "минуты" в crontab не поддерживает имена месяцев или дней недели (это для полей "месяц" и "день недели"). Только числа 0-59, диапазоны, списки и шаги.

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

Способ 1: Прямое редактирование crontab

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

1. Откройте crontab для редактирования:

   crontab -e
   

   
   По умолчанию откроется редактор (обычно nano или vim). Если это первый раз, может предложить выбрать редактор.
2. Найдите строку с ошибкой. Если вы знаете, какое задание не работает, найдите его. Если нет, просмотрите весь файл. Ошибочная строка будет иметь некорректное значение в первом поле. Примеры некорректных строк:

   60 * * * * /path/to/script.sh     # Ошибка: 60 > 59
   */0 * * * * /path/to/script.sh    # Ошибка: шаг 0
   -5 * * * * /path/to/script.sh     # Ошибка: отрицательное число
   * * * * *                        # Корректно (каждую минуту)
   

   
   Примеры корректных строк:

   0 * * * * /path/to/script.sh      # Каждый час в 0 минут
   */5 * * * * /path/to/script.sh    # Каждые 5 минут
   0-30/5 * * * * /path/to/script.sh # Каждые 5 минут с 0 по 30
   

3. Исправьте поле минут на допустимое значение (0-59, диапазон, шаг, список). Сохраните файл и выйдите из редактора.
   • В nano: Ctrl+X, затем Y (сохранить), Enter (подтвердить имя).
   • В vim: :wq, затем Enter.
4. Убедитесь, что crontab загружен. Команда crontab -e автоматически проверяет синтаксис при сохранении и сообщит об ошибке, если она осталась. Если сохранение прошло без предупреждений, синтаксис корректен.
5. Проверьте логи через 1-2 минуты, чтобы убедиться, что ошибка исчезла:

   grep -i "bad minute" /var/log/syslog
   

Способ 2: Валидация через crontab -l и внешние инструменты

Если crontab большой или вы не уверены в синтаксисе, используйте дополнительные методы проверки.

1. Выведите текущий crontab в файл и проверьте вручную:

   crontab -l > mycron.txt
   

   
   Откройте mycron.txt в любом редакторе и внимательно проверьте первое поле каждой строки.
2. Используйте онлайн-валидатор для сложных расписаний. Откройте crontab.guru и введите ваше расписание (первые 5 полей). Сервис покажет, как часто оно сработает, и подсветит ошибки.
3. Проверьте синтаксис с помощью утилиты crontab (некоторые дистрибутивы):

   crontab -c -l  # Флаг -c может проверять синтаксис (зависит от версии cron)
   

   
   Если команда недоступна, полагайтесь на логи.

Способ 3: Анализ системных логов для поиска конкретной строки

Если вы не знаете, в каком именно crontab (пользовательском или системном) ошибка, ищите в логах.

1. Просмотрите логи cron. В зависимости от дистрибутива:
   • Ubuntu/Debian:

     sudo grep -i "bad minute" /var/log/syslog
     

   • CentOS/RHEL/Fedora:

     sudo grep -i "bad minute" /var/log/cron
     

   • Systemd-системы (современные):

     sudo journalctl -u cron -b | grep -i "bad minute"
     # или для crond
     sudo journalctl -u crond -b | grep -i "bad minute"
     

2. В выводе вы увидите временную метку и имя пользователя, чей crontab вызвал ошибку. Пример:

   Feb 17 10:15:01 server CRON[12345]: (user) BAD MINUTE (60)
   

   
   Это означает, что у пользователя user в его crontab есть строка, где в поле минут указано 60.
3. Перейдите к crontab этого пользователя (если это вы, то crontab -e; если другой пользователь, то sudo crontab -u username -e) и исправьте указанное значение.

Способ 4: Проверка системного crontab (/etc/crontab) и файлов в /etc/cron.d/

Ошибка может быть не в пользовательском crontab, а в системном расписании.

1. Проверьте системный crontab:

   sudo cat /etc/crontab
   

   
   Формат здесь отличается: после минут идут часы, день месяца, месяц, день недели, ПОЛЬЗОВАТЕЛЬ, а затем команда. Убедитесь, что поле минут корректно.
2. Проверьте дополнительные файлы в /etc/cron.d/:

   sudo ls /etc/cron.d/
   sudo cat /etc/cron.d/*  # Просмотрите каждый файл
   

   
   Эти файлы используют тот же синтаксис, что и /etc/crontab (с указанием пользователя). Ищите некорректные значения минут.
3. Исправьте найденные ошибки с помощью sudo nano или sudo vim.

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

Чтобы избежать ошибки "bad minute" в будущем:

• Всегда проверяйте диапазон 0-59 для поля минут. Запомните: 60 минут в часе нет.
• Используйте проверенные шаблоны:
  • */N — каждые N минут (N от 1 до 59).
  • M-N — диапазон от M до N (оба в 0-59).
  • M,N,O — список конкретных минут.
  • M-N/K — диапазон с шагом K.
• Тестируйте сложные расписания на crontab.guru перед добавлением в crontab.
• Регулярно просматривайте логи cron (grep CRON /var/log/syslog) на наличие других предупреждений.
• При добавлении новых заданий проверяйте синтаксис сразу после сохранения crontab. Текстовый редактор nano часто подсвечивает синтаксис, но окончательную проверку делает сам cron.
• Для критических заданий добавляйте простой тестовый скрипт, который пишет в файл, и проверяйте его выполнение через несколько минут после настройки.

Следуя этим правилам, вы гарантированно избежите синтаксических ошибок в cron и обеспечите надёжную работу планировщика.