Не запускается crontab linux

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

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

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

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

5 ответов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Предоставьте подходящую PATH в файле crontab

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

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

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

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

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

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

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

Я помещаю файл в /etc/cron. и он не запускает

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Почему не работают скрипты crontab?

Часто, crontab сценарии не выполняются по расписанию или как ожидается. Для этого есть множество причин:

1. неправильная запись crontab
2. проблема с разрешениями
3. переменные среды

Вики-сообщество призвано объединить основные причины crontab сценарии не выполняются, как ожидалось. Запишите каждую причину в отдельном ответе.

Пожалуйста, включите одну причину для ответа — подробности о том, почему он не выполнен — ​​и исправьте (и) по этой одной причине.

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

46 ответов

Другая среда

Cron передает минимальный набор переменных среды для ваших заданий. Чтобы увидеть разницу, добавьте фиктивную работу вот так:

Ждать /tmp/env.output чтобы быть созданным, затем удалите работу снова. Теперь сравните содержимое /tmp/env.output с выходом env запустить в своем обычном терминале.

Распространенная «гоча» здесь PATH Переменная окружения отличается. Может быть, ваш скрипт cron использует команду somecommand нашел в /opt/someApp/bin , который вы добавили в PATH в /etc/environment ? Крон игнорирует PATH из этого файла, так что бег somecommand из вашего скрипта не получится при запуске с cron, но сработает при запуске в терминале. Стоит отметить, что переменные из /etc/environment будут переданы заданиям cron, но не переменным, которые специально устанавливает сам cron, таким как PATH ,

Чтобы обойти это, просто установите свой собственный PATH переменная в верхней части скрипта. Например

Некоторые предпочитают просто использовать абсолютные пути ко всем командам. Я рекомендую против этого. Подумайте, что произойдет, если вы хотите запустить свой скрипт в другой системе, и в этой системе команда находится в /opt/someAppv2.2/bin вместо. Вам придется пройти весь сценарий, заменив /opt/someApp/bin с /opt/someAppv2.2/bin вместо того, чтобы делать небольшое редактирование в первой строке скрипта.

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

Мой главный вопрос: если вы забудете добавить новую строку в конце crontab файл. Другими словами, файл crontab должен заканчиваться пустой строкой.

Ниже приведен соответствующий раздел в справочных страницах по этому вопросу ( man crontab потом переходи до конца)

Cron демон не работает. Я действительно облажался с этим несколько месяцев назад.

Если вы не видите номера, значит, cron не запущен. sudo /etc/init.d/cron start можно использовать для запуска cron.

РЕДАКТИРОВАТЬ: Вместо того, чтобы вызывать сценарии инициализации через /etc/init.d, используйте служебную утилиту, например

Имя файла скрипта в cron.d/ , cron.daily/ , cron.hourly/ и т. д., не должны содержать точку ( . ), иначе run-parts пропустит их.

Итак, если у вас есть скрипт cron backup.sh , analyze-logs.pl в cron.daily/ каталог, вам лучше удалить имена расширений.

Во многих средах cron выполняет команды, используя sh в то время как многие люди предполагают, что он будет использовать bash ,

Предложения для проверки или исправления ошибки команды:

Попробуйте запустить команду в sh чтобы увидеть, работает ли это:

Оберните команду в подоболочку bash, чтобы убедиться, что она запускается в bash:

Скажите cron запустить все команды в bash, установив оболочку в верхней части вашего crontab:

Если команда является скриптом, убедитесь, что скрипт содержит шебанг:

У меня были некоторые проблемы с часовыми поясами. Cron работал со свежим часовым поясом установки. Решение было перезапустить cron:

Абсолютный путь должен использоваться для скриптов:

Например, /bin/grep следует использовать вместо grep :

Это особенно сложно, потому что та же команда будет работать при запуске из оболочки. Причина в том, что cron не имеет то же самое PATH переменная окружения как пользователь.

Если ваша команда crontab имеет % символ в этом, cron пытается интерпретировать это. Так что, если вы использовали какую-либо команду с % в нем (например, указание формата для команды date) вам необходимо его избежать.

Cron вызывает скрипт, который не является исполняемым.

Запустив chmod +x /path/to/scrip скрипт становится исполняемым и должен решить эту проблему.

Также возможно, что срок действия пароля пользователя истек. Даже пароль root может истечь. Вы можете tail -f /var/log/cron.log и вы увидите сбой cron с истекшим сроком действия пароля. Вы можете установить пароль, чтобы никогда не истек, делая это: passwd -x -1

В некоторых системах (Debian, Ubuntu) ведение журнала для cron не включено по умолчанию. В /etc/rsyslog.conf или /etc/rsyslog.d/50-default.conf строка:

следует отредактировать ( sudo nano /etc/rsyslog.conf ) оставлено без комментариев:

После этого вам нужно перезапустить rsyslog через

В некоторых системах (Ubuntu) отдельный файл регистрации для cron не включен по умолчанию, но связанные с cron журналы появляются в файле syslog. Можно использовать

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

Если ваш cronjob вызывает GUI-приложения, вы должны сообщить им, какой DISPLAY они должны использовать.

Пример: запуск Firefox с помощью cron.

Ваш скрипт должен содержать export DISPLAY=:0 где-то.

Боюсь, проблемы с разрешениями встречаются довольно часто.

Обратите внимание, что распространенным обходным решением является выполнение всего, используя crontab root, который иногда является действительно плохой идеей. Установка правильных разрешений — определенно упущенная проблема.

Небезопасное разрешение таблицы cron

Таблица cron отклоняется, если ее разрешение небезопасно

Проблема решена с

Сценарий зависит от местоположения. Это связано с тем, что в скрипте всегда используются абсолютные пути, но это не совсем одно и то же. Ваша работа cron может потребоваться cd перед запуском в конкретный каталог, например, задача rake в приложении Rails может потребоваться в корне приложения для Rake, чтобы найти правильную задачу, не говоря уже о соответствующей конфигурации базы данных и т. д.

Итак, запись в crontab

23 3 * * * /usr/bin/rake db:session_purge RAILS_ENV=production

будет лучше как

Или, чтобы сделать запись в crontab более простой и менее хрупкой:

23 3 * * * /home/ /scripts/session-purge.sh

со следующим кодом в /home/ /scripts/session-purge.sh :

Спецификации Crontab, которые работали в прошлом, могут сломаться при перемещении из одного файла crontab в другой. Иногда причина в том, что вы переместили спецификацию из системного файла crontab в пользовательский файл crontab или наоборот.

Формат спецификации задания cron отличается в файлах crontab пользователей (/var/spool/cron/username или /var/spool/cron/crontabs/username) и системных crontabs ( /etc/crontab и файлы в /etc/cron.d ).

Системные crontabs имеют дополнительное поле ‘user’ прямо перед командой для запуска.

Это приведет к ошибкам с указанием таких вещей, как george; command not found когда вы перемещаете команду из /etc/crontab или файл в /etc/cron.d в файл crontab пользователя.

И наоборот, cron будет выдавать такие ошибки, как /usr/bin/restartxyz is not a valid username или подобное, когда происходит обратное.

Сценарий cron вызывает команду с параметром —verbose

У меня произошел сбой скрипта cron, потому что я набирал скрипт на автопилоте и включил опцию —verbose:

Сценарий выполнялся нормально при выполнении из оболочки, но не работал при запуске из crontab, поскольку подробный вывод выводится на стандартный вывод при запуске из оболочки, но нигде при запуске из crontab. Легко исправить, чтобы удалить «V»:

Самая частая причина, по которой я видел сбой cron в неверно указанном расписании. Требуется практика, чтобы указать работу, запланированную на 23:15 как 30 23 * * * вместо * * 11 15 * или же 11 15 * * * , День недели для рабочих мест после полуночи также сбивается с толку 2-6 после полуночи нет 1-5 , Конкретные даты обычно являются проблемой, так как мы редко их используем * * 3 1 * не 3 марта.

Если вы работаете с различными платформами, используя неподдерживаемые параметры, такие как 2/3 во времени спецификации также могут вызвать сбои. Это очень полезная опция, но она не всегда доступна. Я также сталкивался с проблемами, такие как списки 1-5 или же 1,3,5 ,

Использование неквалифицированных путей также вызвало проблемы. Путь по умолчанию обычно /bin:/usr/bin поэтому будут выполняться только стандартные команды. Эти каталоги обычно не имеют желаемой команды. Это также влияет на сценарии, использующие нестандартные команды. Другие переменные среды также могут отсутствовать.

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

/bin. Это комментируется повсюду и заканчивается строкой # EOF , Это загружается ежедневно из записи в crontab, например:

Приведенная выше команда reload опирается на исполняемый файл crontab с путём взрыва, на котором выполняется crontab. В некоторых системах требуется запуск crontab в команде и указание файла. Если каталог является сетевым, то я часто использую crontab.$(hostname) как имя файла. Это в конечном итоге исправит случаи, когда неправильный crontab загружается на неправильный сервер.

Использование файла обеспечивает резервное копирование того, каким должен быть crontab, и позволяет выполнять временные изменения (единственный раз, когда я использую crontab -e ) для автоматического возврата. Доступны заголовки, которые помогают правильно настроить параметры планирования. Я добавил их, когда неопытные пользователи будут редактировать crontab.

Редко я сталкивался с командами, которые требуют ввода пользователя. Они терпят неудачу при crontab, хотя некоторые будут работать с перенаправлением ввода.

Источник