Debian 10 crontab не работает

Заключение:

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

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Источник

Почему мой crontab не работает, и как я могу устранить его?

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

Ответ: « Почему мой crontab не работает, и как я могу устранить его? ‘можно увидеть ниже. Это относится к cron системе с выделенным crontab.

Как исправить все ваши проблемы / проблемы, связанные с crontab (Linux)

Это вики сообщества , если вы заметили что-то неправильное в этом ответе или у вас есть дополнительная информация, пожалуйста, отредактируйте ее.

Во-первых, основная терминология:

• cron (8) — это демон, который выполняет запланированные команды.
• crontab (1) — программа, используемая для изменения пользовательских файлов crontab (5).
• crontab (5) — это файл для каждого пользователя, который содержит инструкции для cron (8).

Далее образование о cron:

Каждый пользователь в системе может иметь свой собственный файл crontab. Расположение корневых и пользовательских файлов crontab зависит от системы, но обычно они указаны ниже /var/spool/cron .

Существует общесистемный /etc/crontab файл, /etc/cron.d каталог может содержать фрагменты crontab, которые также читаются и обрабатываются cron. Некоторые дистрибутивы Linux (например, Red Hat) также имеют /etc/cron. каталоги, скрипты внутри которых будут выполняться каждый час / день / неделю / месяц с привилегиями root.

root всегда может использовать команду crontab; обычные пользователи могут или не могут получить доступ. Когда вы редактируете файл crontab с помощью команды crontab -e и сохраняете его, crond проверяет его на базовую достоверность, но не гарантирует, что ваш файл crontab сформирован правильно. Существует файл с именем, в cron.deny котором будет указано, какие пользователи не могут использовать cron. Расположение cron.deny файла зависит от системы и может быть удалено, что позволит всем пользователям использовать cron.

Если компьютер не включен или демон crond не запущен, а дата / время выполнения команды истекли, crond не выполнит догон и не выполнит прошлые запросы.

Подробности crontab, как сформулировать команду:

Команда crontab представлена ​​одной строкой. Вы не можете использовать \ для расширения команды на несколько строк. Знак hash ( # ) представляет комментарий, который означает, что все в этой строке игнорируется cron. Ведущие пробелы и пустые строки игнорируются.

Будьте ОЧЕНЬ осторожны при использовании % знака процента ( ) в вашей команде. Если они не экранированы, \% они преобразуются в символы новой строки, и все, что после первого неэкранированного % , передается вашей команде на стандартный ввод.

Существует два формата файлов crontab:

Система в целом /etc/crontab и /etc/cron.d фрагменты

Обратите внимание, что последний требует имени пользователя. Команда будет запущена от имени указанного пользователя.

Первые 5 полей строки представляют время, когда команда должна быть запущена. Вы можете использовать числа или, где это применимо, названия дней / месяцев в спецификации времени.

• Поля разделены пробелами или табуляцией.
• Запятая ( , ) используется для указания списка, например, 1,4,6,8, что означает 1,4,6,8.
• Диапазоны указываются с помощью тире ( — ) и могут сочетаться со списками, например 1-3,9-12, что означает от 1 до 3, затем от 9 до 12.
• Символ / может быть использован, чтобы ввести шаг, например, 2/5, что означает, начиная с 2, затем каждые 5 (2,7,12,17,22 . ). Они не закрывают конец.
• Звездочка ( * ) в поле обозначает весь диапазон для этого поля (например, 0-59 для минутного поля).
• Диапазоны и шаги могут быть объединены, например, */2 означает, начиная с минимума для соответствующего поля, затем каждые 2, например, 0 для минут (0,2 . 58), 1 для месяцев (1,3 . 11) и т. Д.

Отладка команд cron

Проверьте почту!

По умолчанию cron отправляет любые выходные данные команды пользователю, для которого она выполняет команду. Если нет вывода, не будет почты. Если вы хотите, чтобы cron отправлял почту на другую учетную запись, вы можете установить переменную среды MAILTO в файле crontab, например

Захватите результат самостоятельно

Вы можете перенаправить stdout и stderr в файл. Точный синтаксис для захвата вывода может варьироваться в зависимости от того, что использует оболочка cron. Вот два примера, которые сохраняют весь вывод в файл по адресу /tmp/mycommand.log :

Посмотри логи

Cron регистрирует свои действия через системный журнал, который (в зависимости от вашей настройки) часто идет в /var/log/cron или /var/log/syslog .

При необходимости вы можете отфильтровать операторы cron, например:

Теперь, когда мы рассмотрели основы cron, где находятся файлы и как их использовать, давайте рассмотрим некоторые распространенные проблемы.

Проверьте, что cron работает

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

должен получить что-то вроде

Если нет, перезапустите его

Там могут быть другие методы; используйте то, что обеспечивает ваш дистрибутив.

cron запускает вашу команду в ограниченной среде.

Какие переменные среды доступны, вероятно, будет очень ограниченным. Как правило, вы получите только несколько переменных , определенных, например $LOGNAME , $HOME и $PATH .

Особого внимания заслуживает PATH только /bin:/usr/bin . Подавляющее большинство проблем «мой cron скрипт не работает» вызван этим ограничительным путем . Если ваша команда находится в другом месте, вы можете решить эту проблему несколькими способами:

Укажите полный путь к вашей команде.

Укажите подходящий путь в файле crontab

Если вашей команде требуются другие переменные окружения, вы также можете определить их в файле crontab.

cron запускает вашу команду с помощью cwd == $ HOME

Независимо от того, где исполняемая программа находится в файловой системе, текущий рабочий каталог программы при запуске cron будет домашним каталогом пользователя . Если вы обращаетесь к файлам в своей программе, вам необходимо принять это во внимание, если вы используете относительные пути или (предпочтительно) просто везде используете полные пути и избавите всех от путаницы.

Последняя команда в моем crontab не запускается

Cron обычно требует, чтобы команды заканчивались новой строкой. Отредактируйте свой crontab; перейдите в конец строки, содержащей последнюю команду, и вставьте новую строку (нажмите ввод).

Проверьте формат crontab

Вы не можете использовать пользовательский crontab в формате / crontab для / etc / crontab или фрагменты в /etc/cron.d и наоборот. Crontab, отформатированный пользователем, не содержит имя пользователя в 6-й позиции строки, в то время как crontab, отформатированный системой, включает имя пользователя и запускает команду от имени этого пользователя.

Я помещаю файл в /etc/cron. enjhourly,daily,weekly,monthly>, и он не запускается

• Убедитесь, что имя файла не имеет расширения, см. Run-parts
• Убедитесь, что файл имеет разрешения на выполнение.
• Скажите системе, что использовать при выполнении вашего скрипта (например, поставить #!/bin/sh сверху)

Cron даты, связанные с ошибками

Если ваша дата была недавно изменена в результате обновления пользователя или системы, часового пояса или другого, то crontab начнет работать неправильно и выдает странные ошибки, иногда работающие, иногда нет. Это попытка crontab попытаться «сделать то, что вы хотите», когда время изменится из-под него. Поле «минуты» станет недействительным после смены часа. В этом случае принимаются только звездочки. Перезапустите cron и попробуйте снова, не подключаясь к Интернету (чтобы у даты не было возможности перезагрузить один из серверов времени).

Знаки процента, опять

Чтобы подчеркнуть совет о знаках процента, вот пример того, что cron делает с ними:

/ cron.out, содержащий 3 строки

Это особенно навязчиво при использовании date команды. Обязательно избегайте знаков процента

Debian Linux и его производные (Ubuntu, Mint и т. Д.) Имеют некоторые особенности, которые могут помешать выполнению ваших заданий cron; в частности, файлы в /etc/cron.d , /etc/cron. должны:

• быть владельцем root
• быть доступным для записи только пользователю root
• не может быть доступно для записи группе или другим пользователям
• иметь имя без точек «.» или любой другой специальный символ, кроме «-» и «_».

Последний ранит регулярно ничего не подозревающих пользователей; в частности , любой скрипт , в одной из этих папок с именем whatever.sh , mycron.py , testfile.pl и т.д. , будут не выполняться, когда — либо.

По моему опыту, этот конкретный момент был наиболее частой причиной невыполнения cronjob в Debian и его производных.

Смотрите man cron для более подробной информации, если это необходимо.

Если ваши cronjobs перестают работать, проверьте, что срок действия вашего пароля не истек., Поскольку после этого все задания cron прекращаются.
Будут сообщения, /var/log/messages подобные приведенным ниже, которые показывают проблемы с аутентификацией пользователя:

(username) FAILED to authorize user with PAM (Authentication token is no longer valid; new one required)

Необычные и нерегулярные графики

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

Рассмотрим следующую работу, которая обычно объясняется как «запускать command каждые 5 минут» :

который не всегда работает command каждые 7 минут .

Помните, что / символ может быть использован для введения шага, но шаги не переносятся за пределы конца серии, например, */7 который соответствует каждой седьмой минуте минут, 0-59 т.е. 0,7,14,21,28,35,42,49, 56 , но между один час и следующий будет только 4 минуты между партиями , после того, как 00:56 новая серия начинается 01:00 , и 01:07 т.д. (и партии не будет работать на 01:03 , 01:10 , и 01:17 т.д.).

Что делать вместо этого?

Создать несколько партий

Вместо одного задания cron создайте несколько пакетов, которые в результате приведут к желаемому расписанию.

Например, чтобы запускать пакет каждые 40 минут (00:00, 00:40, 01:20, 02:00 и т. Д.), Создайте две партии: одну, которая запускается дважды в четные часы, и вторую, которая запускает только нечетные часы:

Запускайте свои партии реже

Вместо того, чтобы запускать пакет каждые 7 минут, что является сложным графиком для разбивки на несколько пакетов, просто запустите его каждые 10 минут.

Запускайте свои партии чаще (но не допускайте одновременного запуска нескольких партий)

Многие нечетные расписания развиваются, потому что время выполнения пакета увеличивается / колеблется, а затем партии планируются с небольшим дополнительным запасом прочности, чтобы предотвратить одновременное наложение и запуск последующих запусков одной и той же партии.

Вместо этого думайте по-другому и создайте cronjob, который изящно потерпит неудачу, когда предыдущий прогон еще не закончился, но который будет работать иначе. Смотрите этот Q & A :

Это почти сразу же начнет новый запуск после того, как завершится предыдущий запуск / usr / local / bin / частый_cron_job.

Начните свои партии чаще (но выходите изящно, когда условия не правильны)

Поскольку синтаксис cron ограничен, вы можете решить разместить более сложные условия и логику в самом пакетном задании (или в сценарии-оболочке вокруг существующего пакетного задания). Это позволяет вам использовать расширенные возможности ваших любимых языков сценариев, комментировать ваш код и предотвращать трудно читаемые конструкции в самой записи crontab.

В bash, то seven-minute-job будет выглядеть примерно так:

Который вы можете затем безопасно (попытаться) запустить каждую минуту:

Другая, но похожая проблема заключалась бы в том, чтобы запланировать запуск пакета в первый понедельник каждого месяца (или во вторую среду) и т. Д. Просто запланируйте запуск пакета каждый понедельник и выходите, когда дата не находится между 1- м или 7- м и день недели не понедельник.

Который вы можете безопасно (попытаться) запустить каждый понедельник:

Не используйте cron

Если ваши потребности сложны, вы можете рассмотреть возможность использования более продвинутого продукта, который предназначен для запуска сложных расписаний (распределенных по нескольким серверам) и который поддерживает триггеры, зависимости заданий, обработку ошибок, повторные попытки и мониторинг повторных попыток и т. Д. » планирование работы и / или„автоматизация рабочей нагрузки“.

PHP конкретные

Если у вас есть работа cron, например:

И в случае ошибок ожидайте, что они будут отправлены вам, а они нет — проверьте это.

PHP по умолчанию не отправляет ошибки в STDOUT. @ смотри https://bugs.php.net/bug.php?id=22839

Чтобы исправить это, добавьте в файл php.ini или в свою строку (или в свою оболочку bash для PHP) эти:

• —define display_startup_errors = 1
• —define display_errors = ‘stderr’

Первая настройка позволит вам иметь летальные исходы, такие как «Memory oops», а вторая — перенаправить их всех в STDERR. Только после того, как вы сможете хорошо выспаться, все будет отправлено на почту вашего root, а не только в журнал.

Добавив мой ответ отсюда для полноты, и добавив еще один потенциально полезный ресурс:

cron Пользователь имеет другой , $PATH чем вы:

Частая проблема пользователи делают с crontab записями в том , что они забывают , что cron работает в другом , environment чем они делают, вошедшим в системе пользователя. Например, пользователь создает программу или сценарий в своем $HOME каталоге и вводит следующую команду для его запуска:

Команда отлично запускается из его командной строки. Затем пользователь добавляет эту команду к своей crontab , но находит, что это не работает:

Причиной сбоя в этом случае является то, что ./ местоположение cron пользователя отличается от местоположения вошедшего в систему пользователя. То environment есть отличается! PATH является частью environment , и он обычно отличается для cron пользователя. Осложняет эту проблему то, что environment for cron не одинаков для всех дистрибутивов * nix , и существует несколько версий cron

Простое решение этой конкретной проблемы — дать cron пользователю полную спецификацию пути в crontab записи:

Что такое cron пользователь environment ?

В некоторых случаях нам может понадобиться полная environment спецификация для cron нашей системы (или нам может быть просто любопытно). Что такое environment для cron пользователя и чем оно отличается от нашего? Кроме того, нам может потребоваться информация environment для другого cron пользователя — root например . что root пользователь environment использует cron ? Один из способов узнать это — попросить cron нас сказать:

Создайте сценарий оболочки в вашей домашней директории (

/ ) следующим образом (или с вашим редактором):