Centos не работает crontab

Заключение:

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

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

Источник

Почему не работает Crontab в CentOS 7?

Лог файл показывает что задача была выполнена но по факту скрипт не запустился

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

Для уверенности:
1) В начале скрипта запишите что-то в какой-то файл
2) В конце скрипта в этот же файл запишите что выполнено
3) И не пренебрегайте выводом логов при добалении в крон
/home/admin/Telegram_bot/main.py >> /home/admin/Telegram_bot/main.log 2>&1

И да, у пайтона есть свой шедуллер — python-crontab

Частая проблема — Глобальные переменные залогиненых пользователей и пользователя запускаемого по крону могут отличаться (как их наличие так и параметры) — тут нужно смотреть вашу систему.

Укажите в теме строчку из crontab -e и /etc/crontab — я не могу с этого поста зайти к вам в систему и увдеть, а не опечатались ли вы. По конкретике можно, что-то сказать.

Допускаю, что скрипт может не иметь атрибута Исполняемый или неправильно сама команда на исполнение скрипта написана.
Других причин не работать не вижу.

Если в системе есть Пользователь и вы работаете в его среде, то при вводе в Терминал:
crontab -e
задание пишется в файл:
/var/spool/cron/имя_пользователя_в_системе
работать не будет.

Надо:
sudo crontab -e
и тогда уже задание пишется в файл:
/var/spool/cron/root
и так вот будет работать.
И обязательно апосля выполнить:
sudo /etc/init.d/cron restart

Можно в Терминале сразу, без открытия редактора и ручного ввода внести задание двумя способами:
1. Если задание ни разу вообще не добавлялось в системе в crontab, например:
и в этом случае перезагружать cron не надо.

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

2. Если задание уже добавлялось в системе в crontab, то добавить новое можно так, например:
в этом случае задание добавляется новой строкой в файл и уже перегрузка cron нужна, что в коде и присутствует.

Этот же, второй способ добавляет новой строкой и новое задание, если применялся Способ №1.

Источник

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

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

неправильные разрешения для обозначения нот кнтабата.

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

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

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

29 ответов

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

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

Демон Cron не работает.

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

EDIT: вместо вызова сценариев инициализации через /etc/init.d используйте служебную утилиту, например

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

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

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

Предложения по проверке или исправлению этого для команды сбоя:

Попробуйте запустить команду в sh, чтобы увидеть, работает ли она. Завершите команду в подошве bash, чтобы убедиться, что она запущена в bash: bash -c «mybashcommand» Скажите cron, чтобы запустить все команды в bash, установив оболочку в верхней части вашего crontab : SHELL=/bin/bash Если команда является скриптом, убедитесь, что скрипт содержит shebang: #!/bin/bash

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

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

Это и другие хорошие ошибки здесь: http: // www.pantz.org/software/cron/croninfo.html

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

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

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

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

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

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

После этого вам необходимо перезапустить rsyslog с помощью

Источник: Включить ведение журнала crontab в Debian Linux

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

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

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

Если ваш 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

будет лучше, чем

23 3 * * * cd /var/www/production/current && /usr/bin/rake db:session_purge RAILS_ENV=production

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

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

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

cd /var/www/production/current /usr/bin/rake db:session_purge RAILS_ENV=production

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

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

В системе crontabs есть дополнительное поле «пользователь», прямо перед командой для запуска.

Это приведет к ошибкам, указывающим на такие вещи, как , которые работали в прошлом , когда вы перемещаете команду из /etc/crontab или файла в [ f5] в файл crontab пользователя.

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

cron script вызывает команду с опцией -verbose

У меня был сценарий cron сбой, потому что я был в автопилоте, набирая скрипт, и я включил параметр -verbose: [!d1 ]

Скрипт отлично работает при выполнении из оболочки, но не работает при запуске crontab, потому что подробный вывод идет на stdout при запуске из оболочки, но нигде не запускается crontab. Легко исправить удаление ‘v’:

Наиболее частая причина, по которой я видел cron fail в неверно заявленном графике. Для определения задания, запланированного на 11:15 вечера, требуется 30 23 * * * вместо * * 11 15 * или 11 15 * * *. День недели для работы после полуночи также путает M-F 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, например:

#!/usr/bin/crontab # Reload this crontab # 54 12 * * * $/bin/crontab

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

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

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

Источник