Часто crontab
сценарии не выполняются по расписанию или как ожидалось. Для этого есть множество причин:
- неправильная запись crontab
- проблема с разрешениями
- переменные среды
Вики-сообщество призвано объединить основные причины, по которым crontab
скрипты выполняются не так, как ожидалось. Запишите каждую причину в отдельном ответе.
Пожалуйста, включите одну причину для ответа - подробности о том, почему он не выполнен - и исправьте (и) по этой одной причине.
Пожалуйста, пишите только специфичные для cron проблемы, например команды, которые выполняются как ожидается от оболочки, но ошибочно выполняются cron.
crontab -e
чтобы cron вступил в силу. Например, используя vim, я редактирую файл и использую его:w
для записи, но задание не добавляется в cron, пока я тоже не выйду. Так что я не увижу работу до тех пор, пока я:q
тоже.Ответы:
Другая среда
Cron передает минимальный набор переменных среды для ваших заданий. Чтобы увидеть разницу, добавьте фиктивную работу вот так:
Дождитесь
/tmp/env.output
создания, затем снова удалите задание. Теперь сравните содержимое/tmp/env.output
с выходомenv
запуска в обычном терминале.Общей «ошибкой» здесь является то, что
PATH
переменная окружения отличается. Может быть , ваш хрон сценарий использует командуsomecommand
найденную в/opt/someApp/bin
, который вы добавилиPATH
в/etc/environment
? cron игнорируетPATH
этот файл, поэтому запускsomecommand
из вашего скрипта завершится неудачно при запуске с cron, но будет работать при запуске в терминале. Стоит отметить, что переменные from/etc/environment
будут переданы в задания cron, но не переменные, которые специально устанавливает cron, напримерPATH
.Чтобы обойти это, просто установите свою собственную
PATH
переменную в верхней части скрипта. НапримерНекоторые предпочитают просто использовать абсолютные пути ко всем командам. Я рекомендую против этого. Подумайте, что произойдет, если вы захотите запустить свой сценарий в другой системе, и в этой системе
/opt/someAppv2.2/bin
вместо этой команды. Вы должны были бы пройти через весь сценарий , заменяющего/opt/someApp/bin
с/opt/someAppv2.2/bin
вместо того , чтобы просто делать небольшой редактировать на первой строке сценария.Вы также можете установить переменную PATH в файле crontab, который будет применяться ко всем заданиям cron. Например
источник
env
, я совершенно забыл об этой команде и подумал, что PATH работает. На самом деле в моем случае все было по-другому.Мой главный вопрос: если вы забыли добавить новую
crontab
строку в конце файла. Другими словами, файл crontab должен заканчиваться пустой строкой.Ниже приведен соответствующий раздел на страницах руководства для этой проблемы (
man crontab
затем перейдите к концу):источник
man crontab
в Ubuntu 10.10 говорится: «cron требует, чтобы каждая запись в crontab заканчивалась символом новой строки. Если в последней записи в crontab отсутствует символ новой строки, cron будет считать crontab (по крайней мере, частично) неработающим. и отказаться от его установки. " (И дата в конце 19 апреля 2010 года.)crontab -e
его, проверьте синтаксис файла перед разрешением сохранения, включая проверку на новую строку.-e
опции, и не зависит от редактора.Cron демон не работает. Я действительно облажался с этим несколько месяцев назад.
Тип:
Если вы не видите номера, значит, cron не запущен.
sudo /etc/init.d/cron start
может быть использован для запуска cron.РЕДАКТИРОВАТЬ: Вместо того, чтобы вызывать сценарии инициализации через /etc/init.d, используйте служебную утилиту, например
РЕДАКТИРОВАТЬ: Также вы можете использовать systemctl в современном Linux, например,
источник
pidof cron
что будет опускать результаты для других приложений, которые также имеют слово «cron», например, crontab.sudo service cron start
я получаюstart: Job is already running: cron
service crond start
если его сентос / RHELСценарий для имен файлов в
cron.d/
,cron.daily/
,cron.hourly/
и т.д., не должно содержать точку (.
), в противном случае выполняется-части будет пропускать их.Смотрите run-parts (8):
Итак, если у вас есть cron-скрипт
backup.sh
,analyze-logs.pl
вcron.daily/
каталоге вам лучше удалить имена расширений.источник
run-parts --test
(или другой мнимый вариант, например--debug
, выводил бы файлы, которые он пропускает, включая причину.Во многих средах cron выполняет команды с использованием
sh
, в то время как многие люди предполагают, что он будет использоватьbash
.Предложения для проверки или исправления ошибки команды:
Попробуйте запустить команду,
sh
чтобы увидеть, работает ли она:Оберните команду в подоболочку bash, чтобы убедиться, что она запускается в bash:
Скажите cron запустить все команды в bash, установив оболочку в верхней части вашего crontab:
Если команда является скриптом, убедитесь, что скрипт содержит шебанг:
источник
bash
, но не сcron
. Спасибо!source
в bash, но не sh. В cron / sh используйте точку:. envfile
вместоsource envfile
.sh "mycommand"
говоритsh
запустить mycommand в виде файла сценария. Вы имели в видуsh -c "mycommand"
? Во всяком случае, этот ответ, похоже, касается запуска команды именно в bash, так почему вы добавили командуsh
здесь?У меня были некоторые проблемы с часовыми поясами. Cron работал со свежим часовым поясом установки. Решение было перезапустить cron:
источник
* * * * * touch /tmp/cronworks
ничего не делал, пока естьRELOAD
в cronlog.Абсолютный путь должен использоваться для скриптов:
Например,
/bin/grep
следует использовать вместоgrep
:Вместо:
Это особенно сложно, потому что та же команда будет работать при запуске из оболочки. Причина в том, что
cron
не имеет той жеPATH
переменной среды, что и пользователь.источник
/usr/bin/whatever
путьЕсли в вашей команде crontab есть
%
символ, cron пытается его интерпретировать. Поэтому, если вы использовали какую-либо команду, содержащую%
в себе (например, спецификацию формата для команды date), вам нужно будет ее избежать.Это и другие полезные ошибки здесь:
http://www.pantz.org/software/cron/croninfo.html
источник
date
внутри задания cron tab?Cron вызывает скрипт, который не является исполняемым.
При запуске
chmod +x /path/to/scrip
сценарий становится исполняемым и должен решить эту проблему.источник
cron
, и легко прослеживается, просто пытаясь выполнить/path/to/script
из командной строки.. scriptname
илиsh scriptname
илиbash scriptname
, то это становитсяcron
специфической проблемой.Также возможно, что срок действия пароля пользователя истек. Даже пароль root может истечь. Вы можете
tail -f /var/log/cron.log
и увидите сбой cron с истекшим сроком действия пароля. Вы можете установить пароль, чтобы никогда не истек, делая это:passwd -x -1 <username>
В некоторых системах (Debian, Ubuntu) ведение журнала для cron не включено по умолчанию. В /etc/rsyslog.conf или /etc/rsyslog.d/50-default.conf строка:
должен быть отредактирован (
sudo nano /etc/rsyslog.conf
) без комментариев:После этого вам нужно перезапустить rsyslog через
или же
Источник: Включить ведение журнала crontab в Debian Linux
В некоторых системах (Ubuntu) отдельный файл регистрации для cron не включен по умолчанию, но связанные с cron журналы появляются в файле syslog. Можно использовать
для просмотра сообщений, связанных с cron.
источник
Если ваш cronjob вызывает GUI-приложения, вы должны сообщить им, какой DISPLAY они должны использовать.
Пример: запуск Firefox с помощью cron.
Ваш скрипт должен содержать
export DISPLAY=:0
где-то.источник
* * * * * export DISPLAY=:0 && <command>
Боюсь, проблемы с разрешениями встречаются довольно часто.
Обратите внимание, что распространенным обходным решением является выполнение всего, используя 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/<user>/scripts/session-purge.sh
со следующим кодом в
/home/<user>/scripts/session-purge.sh
:источник
chdir(dirname(__FILE__));
Спецификации 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,
15 23 * * *
вместо* * 11 15 *
или11 15 * * *
. День недели для рабочих мест после полуночи также запутывается, MF -2-6
после полуночи, нет1-5
. Конкретные даты, как правило, являются проблемой, поскольку мы редко используем их* * 3 1 *
не 3 марта. Если вы не уверены, проверьте расписание cron онлайн на https://crontab.guru/ .Если вы работаете с разными платформами, используя неподдерживаемые параметры, такие как
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, хотя некоторые будут работать с перенаправлением ввода.
источник
30 23 * * *
переводится на 23:15?15 23 * * *
. Исправлено сейчас.Если вы получаете доступ к учетной записи с помощью ключей SSH, можно войти в учетную запись, но не заметить, что пароль учетной записи заблокирован (например, из-за истечения срока действия или попытки ввода неверного пароля)
Если система использует PAM и учетная запись заблокирована, это может остановить запуск cronjob. (Я проверял это на Solaris, но не на Ubuntu)
Подобные сообщения вы можете найти в / var / adm / messages:
Все, что вам нужно сделать, это запустить:
как root, чтобы разблокировать учетную запись, и crontab должен снова работать.
источник
Если у вас есть такая команда:
и это не работает, и вы не можете видеть какой-либо вывод, это не обязательно означает, что cron не работает. Сценарий может быть поврежден, и вывод будет передан в stderr, который не будет передан в / tmp / output. Проверьте, что это не так, записав этот вывод:
чтобы увидеть, поможет ли это вам решить вашу проблему.
источник
=== Предупреждение Docker ===
Если вы используете докер,
Я считаю правильным добавить, что мне не удалось заставить cron работать в фоновом режиме.
Чтобы запустить задание cron внутри контейнера, я использовал supervisor и запустил
cron -f
вместе с другим процессом.Изменить: Еще одна проблема - мне также не удалось заставить его работать при запуске контейнера с сетью HOST. Смотрите эту проблему здесь также: https://github.com/phusion/baseimage-docker/issues/144
источник
Я писал сценарий установки оболочки, который создает другой сценарий для очистки старых данных транзакций из базы данных. В качестве части задачи он должен был настроить ежедневную
cron
работу для запуска в произвольное время, когда загрузка базы данных была низкой.Я создал файл
mycronjob
с расписанием cron, именем пользователя и командой и скопировал его в/etc/cron.d
каталог. Мои две ошибки:mycronjob
файл должен был принадлежать пользователю root для запускаПроблема с разрешением будет отображаться
/var/log/syslog
как нечто похожее на:Первая строка относится к
/etc/crontab
файлу, а вторая - к файлу, в который я поместил/etc/cront.d
.источник
Строка написана так, что crontab не понимает. Это должно быть правильно написано. Вот CrontabHowTo .
источник
Cron-демон может быть запущен, но на самом деле не работает. Попробуйте перезапустить cron:
источник
pidof
cron и ничего не получил. Попробовал с помощьюservice
утилиты, и он сказал, что Cron уже работает. Просто запустил эту команду иpidof
снова побежал, и я получил результат.Запись в cron через "crontab -e" с аргументом username в строке. Я видел примеры пользователей (или системных администраторов), пишущих свои сценарии оболочки и не понимающих, почему они не автоматизируют. Аргумент «пользователь» существует в / etc / crontab, но не в пользовательских файлах. так, например, ваш личный файл будет выглядеть примерно так:
тогда как / etc / crontab будет:
Итак, почему вы делаете последнее? Ну, в зависимости от того, как вы хотите установить свои разрешения, это может стать очень запутанным. Я написал сценарии для автоматизации задач для пользователей, которые не разбираются в тонкостях или не хотят беспокоиться о тяжелой работе. Установив права доступа
--x------
, я могу сделать исполняемый скрипт без возможности его чтения (и, возможно, случайного изменения). Тем не менее, я мог бы захотеть запустить эту команду с несколькими другими из одного файла (таким образом, облегчая поддержку), но удостовериться, что выходной файл назначен правильному владельцу. Это (по крайней мере, в Ubuntu 10.10) устраняет как невозможность чтения файла, так и выполнения, а также вышеупомянутую проблему с помещением точек в / etc / crontab (что, как ни странно, не вызывает ошибок при прохожденииcrontab -e
) ,В качестве примера я видел примеры
sudo crontab -e
использования для запуска скрипта с правами root, с соответствующимchown username file_output
в скрипте оболочки. Небрежно, но это работает. ИМХО, более изящный вариант - поставить его/etc/crontab
с объявленным именем пользователя и надлежащими разрешениями, поэтомуfile_output
отправляется в нужное место и владельцу.источник
Основываясь на том, что Аарон Пирт упомянул о подробном режиме, иногда сценарии, не находящиеся в подробном режиме, будут инициализироваться, но не завершаться, если поведение включенной команды по умолчанию будет выводить строку или более на экран после запуска процедуры. Например, я написал сценарий резервного копирования для нашей интрасети, который использовал curl, утилиту, которая загружает или загружает файлы на удаленные серверы, и это очень удобно, если вы можете получить доступ к указанным удаленным файлам только через HTTP. Использование 'curl http://something.com/somefile.xls ' приводило к зависанию написанного мной скрипта, который никогда не завершался, поскольку он выплевывал новую строку, за которой следовала строка прогресса. Мне пришлось использовать флаг без вывода сообщений (-s), чтобы запретить выводить какую-либо информацию, и написать собственный код для обработки, если файл не удалось загрузить.
источник
/dev/null
. Например:some-command > /dev/null
это перенаправит только стандартный вывод, а не вывод ошибок (что обычно и требуется, поскольку вы хотите получать информацию об ошибках). Для перенаправления вывода ошибок тоже используйтеsome-command &> /dev/null
.Хотя вы можете определять переменные окружения в вашем crontable, вы не находитесь в сценарии оболочки. Поэтому конструкции, подобные следующим, не будут работать:
Это потому, что переменные не интерпретируются в crontable: все значения принимаются буквально. И это то же самое, если вы опустите скобки. Таким образом, ваши команды не будут выполняться, а ваши файлы журнала не будут записаны ...
Вместо этого вы должны определить все переменные окружения прямо:
источник
Когда задача запускается в cron, stdin закрывается. Программы, которые работают по-разному в зависимости от того, доступен ли stdin или нет, будут вести себя по-разному между сеансом оболочки и в cron.
Примером является программа
goaccess
для анализа файлов журнала веб-сервера. Это не работает в cron:и
goaccess
показывает страницу справки вместо создания отчета. В оболочке это можно воспроизвести с помощьюРешение
goaccess
проблемы - заставить его читать журнал из stdin вместо чтения из файла, поэтому решение состоит в том, чтобы изменить запись crontab наисточник
В моем случае у cron и crontab были разные владельцы.
Не работает у меня было это:
В основном мне пришлось запустить cron-config и правильно ответить на вопросы. Есть момент, когда мне нужно было ввести мой пароль пользователя Win7 для моей учетной записи «Пользователь». После прочтения, похоже, это потенциальная проблема безопасности, но я единственный администратор в одной домашней сети, поэтому я решил, что все в порядке.
Вот последовательность команд, которая меня подтолкнула:
источник
На моих серверах RHEL7 запускаются задания root cron, а задания пользователей - нет. Я обнаружил, что без домашнего каталога задания не будут выполняться (но вы увидите хорошие ошибки в / var / log / cron). Когда я создал домашний каталог, проблема была решена.
источник
Если вы отредактировали свой файл crontab с помощью редактора Windows (через samba или что-то еще), и он заменил символы новой строки на \ n \ r или просто \ r, cron не запустится.
Кроме того, если вы используете /etc/cron.d/* и в одном из этих файлов есть \ r, cron будет перемещаться по файлам и останавливаться, когда попадет в плохой файл. Не уверен, что это проблема?
Использование:
источник