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

  

Это Канонический вопрос об использовании cron & кронтаб.

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

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

185 голосов | спросил Eric Leschinski 17 62012vEurope/Moscow11bEurope/MoscowSat, 17 Nov 2012 08:51:50 +0400 2012, 08:51:50

5 ответов


266

Как исправить все ваши проблемы /проблемы, связанные с 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 detailss, как сформулировать команду:

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

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

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

  • Пользователь crontabs

    # Пример определения задания:
    # .---------------- минута (0 - 59)
    # | . (0 - 23)
    # | | .---- день месяца (1 - 31)
    # | | | .------- месяц (1 - 12) ИЛИ jan, feb, mar, apr ...
    # | | | | .---- день недели (0 - 6) (воскресенье = 0 или 7)
    # | | | | |
    # * * * * * команда, которая будет выполнена
    
  • Общесистемные фрагменты /etc /crontab и /etc/cron.d

    # Пример определения задания:
    # .---------------- минута (0 - 59)
    # | . (0 - 23)
    # | | .---- день месяца (1 - 31)
    # | | | .------- месяц (1 - 12) ИЛИ jan, feb, mar, apr ...
    # | | | | .---- день недели (0 - 6) (воскресенье = 0 или 7)
    # | | | | |
    # * * * * * команда user-name, которая будет выполнена
    

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

Первые 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 отправит любой результат из команды пользователю, который выполняет команду as. Если нет выхода, почты не будет. Если вы хотите, чтобы cron отправил почту на другую учетную записьто вы можете установить переменную среды MAILTO в файле crontab, например.

[email protected]
1 2 * * * /путь /в /ваш /команда

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

1 2 * * * /path /to /your /command> /tmp/mycommand.log

, который захватывает stdout и stderr в /tmp/mycommand.log

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

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

grep CRON /var /log /syslog

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

Убедитесь, что cron работает

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

ps -ef | grep cron | grep -v grep

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

root 1224 1 0 16 ноября? 00:00:03 cron

или

root 2018 1 0 Nov14? 00:00:06 crond

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

/sbin /service cron start

или

/sbin /запуск сервисов

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

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

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

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

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

    1 2 * * * /path /to /your /command
    
  2. Предоставьте подходящую PATH в файле crontab

    PATH = /USR: /USR /бен: /путь /к /что-то /другое
    1 2 * * * команда
    

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

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

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

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

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

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

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

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

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

Связанные с Cron ошибки

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

Знаки процента, снова

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

# cron entry
* * * * * cat> $ HOME /cron.out% foo% bar% baz

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

Foo
бар
Baz

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

* * * * * /path /to /command --day "$ (date" + \% Y \% m \% d ")"
ответил Bill Cheswick 26 J0000006Europe/Moscow 2018, 17:15:23
18

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

  

(имя пользователя) FAILED для авторизации пользователя с помощью PAM (токен аутентификации больше не действителен, требуется новый)

ответил Munkeh72 9 +04002013-10-09T19:29:06+04:00312013bEurope/MoscowWed, 09 Oct 2013 19:29:06 +0400 2013, 19:29:06
14

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

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

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

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

Подробнее см. man cron

.

ответил wazoox 4 FebruaryEurope/MoscowbThu, 04 Feb 2016 23:29:35 +0300000000pmThu, 04 Feb 2016 23:29:35 +030016 2016, 23:29:35
10

Необычные и нерегулярные расписания

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

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

* /5 * * * * /path /to /your /command

против

* /7 * * * * /path /to /your /command

, который не всегда запускает команду каждые 7 минут .

Помните, что символ / может использоваться для введения шага, но эти шаги не завершаются за пределы серии, например. * /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 и т. д.) создаются две партии, одна из которых выполняется дважды в четные часы, а вторая - только нечетные часы:

# Следующие строки создают пакет, который запускается каждые 40 минут, т. е.

# работает в 0:00, 0:40, 02:00, 02:40 04:00 и т. д. до 22:40
0,40 * /2 * * * /путь /в /ваш /команда

# работает в 01:20, 03:20 и т. д. до 23:20
20 1/2 * * * /path /to /your /command

# Комбинированные: 0:00, 0:40, 01:20, 02:00, 02:40, 03:20, 04:00 и т. Д.

Раньше выполняйте свои партии

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

Раньше выполняйте свои партии

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

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

* * * * * /usr /bin /flock -n /tmp/fcj.lockfile /usr /local /bin /often_cron_job - минимально

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

В bash семиминутная работа будет выглядеть примерно так:

#! /Bin /Баш
# семиминутная работа
# Эта партия будет работать только тогда, когда прошло 420 секунд (7 минут)
# поскольку файл /tmp /lastrun был либо создан, либо обновлен

если [ ! -f /tmp /lastrun]; тогда
    touch /tmp /lastrun
фи

if [$ (($ (date +% s) - $ (date -r /tmp /lastrun +% s))) -lt 420]; тогда
    echo «Минимальный интервал 7 минут между последовательными партиями еще не прошел».
    Выход
фи

echo «Начать запуск вашей партии»

дата> /TMP /LASTRUN

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

* * * * * /path /to /your /seven-minute-job

Не использовать cron

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

ответил HBruijn 17 42016vEurope/Moscow11bEurope/MoscowThu, 17 Nov 2016 17:37:33 +0300 2016, 17:37:33
8

PHP конкретных

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

php /bla/bla/something.php>> /var/logs/somelog-for-stdout.log

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

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

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

  • - define display_startup_errors = 1
  • - определить display_errors = 'stderr'

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

ответил gaRex 23 +04002013-10-23T08:45:58+04:00312013bEurope/MoscowWed, 23 Oct 2013 08:45:58 +0400 2013, 08:45:58

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132