Не работает cron centos

Обновлено: 07.07.2024

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

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

@DanDascalescu Похоже, Эрику нужно больше представителей Я только что присоединился к Server Fault SE (так что всего 101 повтор), но хотел бы дать этому вопросу -1 !! Этот вопрос был задуман только для получения репутации? @IamtheMostStupidPerson Полностью согласен с вами . Западная идеология у этих 13-летних падаванов одновременно и учебная, и ослепительная, как сверхновая. Чтобы ответить на оба ваших вопроса: да, я сделал это для представителя, и да, Эрик должен получить больше репутации. Сколько еще повторений мне нужно ?? Больше. youtu.be/IaDt9T7BF38?t=262

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

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

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

Система в целом /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, например

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

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

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>, и он не запускается

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

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

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

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

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

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

Возможно, вы захотите также упомянуть в разделе «ограниченное env», что LD_LIBRARY_PATH также может потребоваться установить дополнительные каталоги в случае сбоя вашей задачи cron из-за невозможности найти общие библиотеки. обратите внимание, что вы даже можете написать что-то вроде этого: 35 1,5-23 / 2 * * * do_something вместо 35,1,5,7,9, .. * * * Кроме того, этот crontab.guru переводит записи, которые вы делаете в человеческий язык. У меня выходной захват не работает, может быть из-за оболочки sh. Я думаю, что это более переносимо: . /path/to/your/command >/tmp/mycommand.log 2>&1 это сработало для меня: sudo apt-get install postfix работа cron также зависит от того, насколько тяжелый файл? Поскольку я управлял простым привет миром на python с помощью cron, это сработало. Но мой второй код был немного тяжелым и обычно выполнялся, но с помощью cron он не дает никакого вывода в файл.

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

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

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

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

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

(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

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

Помогите неопытному. Операционная система CentOS 6.3. Пытаюсь настроить бэкап папки и базы данных через rsync. Скрипты через консоль запускаются нормально, все работает, крон ошибок при сохранении не выдает, просто пишет "installing new crontab". Если я все правильно понимаю, то вроде все правильно. Но почему-то ничего не работает. Права на папку где лежат скрипты 777.

Сами скрипты:
Первый

Текст crontab

Вопрос задан более трёх лет назад
42042 просмотра

Простой 1 комментарий

Все нашел ответ на свой вопрос:

1) Кронтаб нужно запускать так: sudo crontab -e - это нужно чтобы cron запускал скрипты из под root.
2) Инструкции для cron должны быть такими. Нужно обязательно писать bash перед указанием пути к скрипту. После указания пути к скрипту дописать >/dev/null 2>&1
Пример:

3) Сами скрипты действительно должны быть лишены sudo, так как и так запускаются из под пользователя root.
Пример:

В crontab в конец каждой команды добавьте:
> /tmp/имя_команды.log 2>&1
и почитайте /tmp/*.log

Всё дело в sudo, не используйте его в скриптах если не настроено выполнение без ввода пароля. Если требуется выполнение от root-а, то перенесите задачи крона в root-ый крон.

1. /bin/bash в crontab не нужен. Выкиньте его и сделайте скрипты исполняемыми.
2. приложения из cron запускаются с минимальным environment, если mysqldump не лежит в /bin или /usr/bin, script.sh его не найдёт. Добавьте в скрипт set > /tmp/script-environment чтобы посмотреть, с чем они запускаются.
3. sudo -- нужен nopasswd

Можете объяснить что значит: >/dev/null 2>&1
У меня прописано сейчас вот так:
00 16,18,20,22 * * * garanty /home/garanty/www/garancy.finexpert.pro/ftpset.sh 2>/home/garanty/www/garancy.finexpert.pro/tmp/logscron.txt

Не запускается, хотя в логах пишет, что все нормально.

2>/home/garanty/www/garancy.finexpert.pro/tmp/logscron.txt - эта штука должна записывать в файл logscron.txt ошибки если они будут?

> Можете объяснить что значит: >/dev/null 2>&1
stdout -- в /dev/null, stderr -- туда же, куда stdout

Добавить в избранное

Главное меню » Linux » Почему мой Crontab не работает и как его устранить?

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

Почему мой Crontab не работает?

Определенные причины могут привести к сбою вашего Crontab. Первая и самая главная проблема заключается в том, что ваш демон Cron может не работать по какой-либо причине, что, следовательно, приведет к сбою вашего Crontab. Возможно, переменные среды вашей системы настроены неправильно. В скрипте, который вы пытаетесь выполнить с помощью Crontab, могут быть ошибки. Например, в желаемом сценарии может отсутствовать Shebang, т. е. необходимая последовательность символов в начале сценария. Сценарий, который вы пытаетесь выполнить с помощью Crontab, может быть не исполняемым, т. е. его права доступа ограничены. Возможно, путь к сценарию, который вы пытаетесь выполнить, неверен. Возможно, вам не хватает расширения файла, который вы пытаетесь запустить с помощью Crontab.

Как я могу устранить неисправность моего неисправного Crontab?

В зависимости от фактической причины сбоя Crontab существуют разные способы устранения неполадок. Некоторые из этих способов перечислены ниже:

Заключение:

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

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

21.04.2020

CentOS, Linux

Комментариев пока нет

Cron — это планировщик задач, работающий в Unix-подобных операционных системах, включая все дистрибутивы Linux. Демон cron работает на сервере в фоновом режиме и запускает по расписанию запланированные задачи. В этой статье мы рассмотрим установку cron на сервер с Linux CentOS 8, познакомимся с синтаксисом cron, научимся добавлять в него различные задачи, управлять расписанием запуска.

Установка cron в Linux

По умолчанию cron доступен при установке CentOS 8. Если же у вас по каким-то причинам он отсутствует, вы можете установить его из базового репозитория с помощью yum / dnf:

В моем случае cron уже был установлен:

После установки, демон crond нужно добавить в автозагрузку и запустить:

Crontab: добавление задания в планировщик cron

Для добавления задач в cron можно использовать команду:

Данная команда откроет файл для задач для вашего пользователя в текстовом редакторе по-умолчанию (у меня это vi, но можно изменить на удобный для вас, например nano). Настройка заданий таким способом исключает, что вы допустите ошибку в синтаксисе. Редактор crontab просто не даст сохранить файл с ошибками.

Также можно отредактировать файл заданий cron вручную через mc:

Чтобы добавить простое задание по запуск bash скрипта в cron, выполните:

Теперь добавьте расписание задания и путь к файлу скрипта:

Сохраните файл (редактирование файла по аналогии с редактором vim: сохранить Ctrl+O и выйти Ctrl+x).

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

Данный скрипт будет запускаться через cron ежеминутно.

Минимальное время – 1 минута. Демон cron просматривает список заданий один раз в минуту. Просматриваются следующие файлы и каталог:

Каждая запись расписания crontab состоит из 5 полей:

Можно использовать следующие допустимые значения для каждого из полей:

Поле	Диапазон значений
минуты	0-59
часы	0-23
день месяца	1-31
месяц	1-12 или jan feb mar apr may jun jul aug sep oct nov dec
день недели	0-6 (где 0 это воскресение) или sun mon tue wed thu fri sat

Знак * означает все допустимые значения. Пример задания:

Указанный в задании скрипт, будет запускаться каждый понедельник в 00 часов 15 минут. Для упрощения синтаксиса cron-файла используют специальные символы:

Запятая (,) : запятой разбиваются значения расписания для выполнения одинаковой задачи, но в разное время. Например, если вам нужно выполнять задачу в 15 и 30 минут, вы можете задать расписание так:

Или исползовать более короткий синтаксис с запятой:

Слеш (/) : использовать косую черту можно для выражения какого-либо шага. Например, вам нужно запускать какую-то задачу каждые 2 часа. В обычном написании файл cron будет громоздким, используя / вы заметно сократите содержимое cron файл:

* */2 * * *
Дефис (-) : дефис указывает диапазон значений в поле. Если вы хотите запускать задание первые 10 минут или последние 10 минут, укажите диапазон через дефис:

Еще несколько примеров расписаний для cron:

запуск по будням в 12:00 и 18:00: 0 12,18 * * 1-5
каждые 30 минут: */30 * * * *
каждую субботу: 0 0 * * 6
каждый вторник и четверг в 2:00 ночи: 0 2 * * 2,4

Еще в cron можно использовать специальные переменные.

Т.е. для запуска задания раз в день можно использовать формат:

@daily echo "Проверка cron"

Можно отредактировать cron файл другого пользователя:

Отправка уведомлений cron на e-mail

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

Для отправки почты на сервере дожен быть установлен почтовый-агент. Для теста, я установил на сервер sendmail:

sendmail – бесплатный агент для передачи почты, который доступен практически для любой операционной системе.

Настроем параметры отправки e-mail в cron-файле. Добавьте в файл следующие строки:

После каждого запуска задачи на указанный email отправляется уведомление:

Информацию о запуске задания cron можно сохранять в лог-файл. Для этого, в конце задания нужно добавить >> и указать путь до лог-файла:

* * * * * echo "Проверка cron" >> /var/log/admin/journal.log

Если в вашем cron-файле добавлено много заданий и результат выполнения каких-то из них, не нужно отправлять на почту, данные задания вы можете запускать в «бесшумном» режиме:

* * * * * echo "Проверка cron" >> /dev/null 2>&1

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

Файлы конфигурации и логи планировщика cron

/etc/cron.daily – запуск скриптов один раз в день
/etc/cron.hourly – запуск скриптов ежечасно
/etc/cron.monthly – запуск скриптов раз в месяц
/etc/cron.weekly – запуск скриптов раз в неделю

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

Можно ограничить доступ к планировщику с помощью файлов /etc/cron.allow и /etc/cron.deny. Достаточно создать эти файлы и добавить в него пользователей, которым, соотвественно, разрешено и запрещено запускать задания cron.

В файл /etc/crontab тоже можно помещать задания. Обычно данный файл используется root пользователем или для настройки системных задач. Личные файлы пользователей для cron заданий, хранятся в директории /var/spool/cron/ или /var/cron/tabs/.

Чтобы отследить выполнение задач или отследить ошибки, можно обратиться к лог-файлу /var/log/cron. В данном файле фиксируется запуск всех задач и ошибки в работе демона, если они есть:

Читайте также: