Кронтаб не работает в Ubuntu

Обновлено: 06.07.2024

Crontab (таблица cron) – это файл конфигурации, в котором указываются команды оболочки, которые должны выполняться периодически по заданному расписанию. Он обычно используется для автоматизации обслуживания или администрирования системы. Crontab доступен практически в дистрибутиве Linux и прост в использовании.

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

Причин тому несколько. Ниже приведены 5 основных причин, по которым у нас может быть

1. Программное обеспечение Crontab не установлено

Хотя сегодня Crontab доступен почти в дистрибутиве Linux по умолчанию, существует настроенная версия Linux, в которой отсутствует пакет cron. Чтобы установить крон…

В системах на базе RHEL (RedHat/CentOS/Fedora)

В системах на основе Debian (Debian / Ubuntu / Mint)

Если в вашем дистрибутиве Linux нет менеджера пакетов, вы можете установить cronie из его исходного кода.

2. Ваша служба cron не запущена

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

Также убедитесь, что служба cron запускается при загрузке.

3. Ваш скрипт cron имеет неверное имя файла

Служба Cron поддерживает запуск внешних скриптов, которые помещаются в каталоги cron.d , cron.daily , cron.hourly , cron.monthly и cron.weekly. Согласно RUN-PARTS(8), имена ваших файлов сценариев должны соответствовать следующим правилам:

Если не указан ни параметр –lsbsysinit, ни параметр –regex, то имена должны полностью состоять из букв верхнего и нижнего регистра ASCII, цифр ASCII, знаков подчеркивания ASCII и минус-дефисов ASCII.

Если указан параметр –lsbsysinit, имена не должны заканчиваться на .dpkg-old, .dpkg-dist, .dpkg-new или .dpkg-tmp и должны принадлежать одному или нескольким из следующих пространств имен: назначенное LANANA пространство имен (^[a-z0-9]+$); иерархические и зарезервированные пространства имен LSB (^?([a-z0-9.]+-)+[a-z0-9]+$); и пространство имен сценария хрона Debian (^[a-zA-Z0-9_-]+$).

Если указан параметр –regex, имена должны соответствовать пользовательскому расширенному регулярному выражению, указанному в качестве аргумента этого параметра.

Частая проблема с именами, с которой я обычно сталкиваюсь, связана с использованием символа точки в имени файла, так как мы хотим указать расширение файла при сохранении скрипта. Этот символ точки нарушает правило и заставляет службу cron игнорировать ваш скрипт. Если у вас есть такие скрипты, как backup.sh , переименуйте его в backup .

4. У вашего скрипта cron неправильные права

Сценарий должен быть исполняемым, чтобы служба cron могла его запустить. Чтобы дать исполняемый файл вашему сценарию, вы можете использовать команду chmod. Например:

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

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

5. Ваш скрипт cron не может быть выполнен правильно

На это есть несколько причин. Давайте рассмотрим некоторые распространенные случаи ниже

Шебанг

Отсутствуют переменные среды

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

Если вы используете crontab -e для написания команд cron, возможно, вы захотите загрузить переменные среды, необходимые вашим сценариям/приложениям. Эти переменные можно загрузить напрямую, поставив прямо перед командой, например:

Или загрузить их из файла

Или, если эти переменные загружаются в вашем профиле пользователя, например, в профиле bash. Вы можете указать оболочку в начале crontab.

В системах на базе Linux crontab является хорошо известным планировщиком заданий. Вы всегда можете использовать службы демона cron, если вам нужно выполнить определенные функции, ограниченные по времени. Что делать, если ваш crontab время от времени перестает работать? Вы можете запутаться, выясняя причину этой проблемы. В таком случае вы также опробуете все возможные решения. Пожалуйста, не используйте эти варианты, потому что в этой статье мы предоставим вам несколько оригинальных методов устранения неполадок с вашим crontab. Итак, давайте начнем это путешествие!

Почему crontab не работает в вашей системе?

Crontab может не работать по разным причинам:

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

Устранение неполадок с crontab:

Существует несколько подходов к устранению неполадок с crontab в вашей системе, в зависимости от фактической причины. Мы продемонстрируем вам некоторые из этих методов в следующих разделах.

Демон cron запущен?

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

Если в выходных данных отображается какое-либо число, относящееся к основному PID cron, это означает, что ваш демон cron работает нормально.

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

Теперь проверьте состояние службы cron.

Выполняет ли cron ваше задание cron?

Теперь просмотрите файл системного журнала вашей системы и проверьте наличие ошибок cron.

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

Поднятие cron до уровня отладки:

Еще один способ, который вы можете попробовать, – поднять cron до уровня отладки. Откройте файл «/etc/rsyslog.d/50-default.conf».

Закомментируйте следующую строку в открытом файле конфигурации.

Запишите приведенную ниже команду, чтобы перезагрузить регистратор.

После перезагрузки регистратора повторно запустите cron. Ваш crontab будет отлично работать после выполнения этой процедуры.

Вывод:

Crontab — это популярный планировщик задач, включенный в системный пакет Linux, поскольку он планирует выполнение процесса от имени пользователя root. У вас когда-нибудь возникали проблемы при выполнении любого задания с помощью crontab? Если Да, то Не волнуйтесь! Этот пост вас спасет. Мы предоставили различные способы устранения неполадок с crontab в вашей системе.

Об авторе

Талья Саиф Малик

Талья является участником Linux Hint и стремится приносить пользу и делать полезные вещи для всего мира. Он любит читать, писать и говорить о Linux, данных, компьютерах и технологиях.

Хотите улучшить этот пост? Предоставьте подробные ответы на этот вопрос, включая цитаты и объяснение того, почему ваш ответ правильный. Ответы без достаточной детализации могут быть отредактированы или удалены.

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

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

Я только что присоединился к Server Fault SE (поэтому всего 101 представитель), но хотел бы поставить этому вопросу -1!! Этот вопрос был задан только для того, чтобы получить репутацию? @IamtheMostStupidPerson Полностью с вами согласен.

7 ответов 7

Как исправить все проблемы/проблемы, связанные с crontab (Linux)

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

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

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

Самостоятельный захват результатов

Вы можете перенаправить stdout и stderr в файл. Точный синтаксис для захвата вывода может различаться в зависимости от того, какую оболочку использует cron. Вот два примера, которые сохраняют весь вывод в файл /tmp/mycommand.log:

Просмотрите журналы

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

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

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

Проверьте, запущен ли cron

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

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

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

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

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

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

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

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

Укажите подходящий PATH в файле crontab

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

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

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

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

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

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

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

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

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

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

Снова знаки процента

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

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

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

Остерегайтесь Судо

при работе от имени пользователя без полномочий root,

откроет пользовательский crontab, а

откроет crontab пользователя root. Не рекомендуется запускать команды sudo в задании cron, поэтому, если вы пытаетесь запустить команду sudo в cron пользователя, попробуйте переместить эту команду в cron root и удалить sudo из команды.

Возможно также указать в разделе "restricted 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

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

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

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

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

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

При необходимости см. man cron для получения более подробной информации.

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

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

Только что получил это (файл сообщения об ошибке /var/log/syslog для меня). В моем случае ящик DigitalOcean, который во время создания сбрасывает пароль root (необязательно) на другой, и, по-видимому, пока вы не войдете туда и не измените его, все задания cron не запускаются. облом. Исправление похоже на sudo -u root passwd

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 минут.

Запускайте свои пакеты чаще (но не допускайте одновременного запуска нескольких пакетов)

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

Вместо этого подумайте по-другому и создайте задание cron, которое корректно завершает работу, если предыдущий запуск еще не завершен, но которое будет выполняться в противном случае. См. эти вопросы и ответы:

Это почти сразу же запустит новый запуск после завершения предыдущего запуска /usr/local/bin/frequent_cron_job.

Запускайте свои пакеты чаще (но корректно завершайте работу, если условия не подходят)

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

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

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

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

Который затем можно безопасно (попытаться) запускать каждый понедельник:

Не используйте cron

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

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

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

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

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

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

Вы должны закрыть crontab -e, чтобы cron вступил в силу. Например, с помощью vim я редактирую файл и использую :w для его записи, но задание не добавляется в cron, пока я также не выйду. Так что я не увижу работу до тех пор, пока не :q тоже.

В моем случае электронное письмо направлялось в мою папку СПАМ, так что. проверьте это, прежде чем тратить часы на отладку :D

47 ответов 47

Другая среда

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

Подождите, пока будет создан файл /tmp/env.output, затем снова удалите задание. Теперь сравните содержимое /tmp/env.output с выводом env run в обычном терминале.

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

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

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

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

+1 для env , я совсем забыл об этой команде и думал, что PATH работает. На самом деле в моем случае все было немного иначе.

@pbr Системный администратор может непреднамеренно удалить корневую файловую систему. Вы не можете защититься от глупых ошибок системных администраторов. Если вы установите более новую версию интерпретатора, которая не имеет обратной совместимости, я бы все равно ожидал поломки. Разумный способ справиться с этим — установить его как другую команду. Э.грамм. у вас есть python версии 2.x и вы устанавливаете python 3, вы устанавливаете его как python3, а не python. А что касается /opt/someApp/bin, с какой стати у него не было бы разумных разрешений/прав собственности? любой здравомыслящий администратор обеспечит разумные разрешения/право собственности на системные файлы.

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

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

Кажется, исправлено в Vixie cron: man crontab в Ubuntu 10.10 говорит: «cron требует, чтобы каждая запись в crontab заканчивалась символом новой строки. Если в последней записи в crontab отсутствует новая строка, cron будет рассматривать crontab ( хотя бы частично) сломан и отказываемся от установки." (И дата в конце — 19 апреля 2010 г.)

@barraponto На самом деле это ошибка в новых текстовых редакторах. Предполагается, что символ "новой строки" является символом окончания строки, поэтому последняя строка в текстовом файле должна заканчиваться символом новой строки, который не отображается в редакторе. Vi и vim правильно используют этот символ, а cron был создан до того, как новые редакторы начали вести себя странно. Следовательно, воспроизводить его с сохранением и включать пустую строку.

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

@Chan-HoSuh, согласно справочной странице "cron требует, чтобы каждая запись в crontab заканчивалась символом новой строки. Если в последней записи в crontab отсутствует новая строка, cron будет считать crontab (по крайней мере, частично) сломанным и отказаться от установки." Это поведение будет вызываться при редактировании, а затем сохранении crontab с помощью параметра -e и не зависит от редактора.

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

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

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

EDIT: Также вы можете использовать systemctl в современном Linux, например,

Вы также можете использовать pidof cron, который пропустит результаты для других приложений, которые также содержат слово "cron", например crontab.

Странно, все это не дает мне ничего, чтобы показать, что cron работает, но если я запускаю sudo service cron start, я получаю старт: Задание уже запущено: cron

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

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

Это функция, а не ошибка. Она не позволяет запускать такие вещи, как myscript.backup, myscript.original или myscript.rpm-new рядом с myscript.

@pbr: имеет смысл. По крайней мере, для отладки было бы полезно, если бы run-parts --test (или другая воображаемая опция, такая как --debug) выводила бы пропущенные файлы с указанием причины.

Если это функция, то она нехорошая :( Многие люди используют точку в имени файла (наиболее распространенной является backup.sh). Если вы хотите, чтобы скрипт прекратил выполнение, самый логичный способ будет удалить его из каталога "cron.d".

Это настолько плохая функция, что фактически является ошибкой. Обычной практикой является требование определенного окончания (например, «.list» или «.cron» или что-то в этом роде), если люди хотят убедиться, что что-то запускается только по назначению. Произвольный выбор точки в качестве вероятного разделителя для «.bak» или «.temp» или чего-либо еще совершенно непредсказуем, за исключением того, что это предсказуемо запутает людей. Законные окончания, такие как «.sh» и «.pl», широко использовались на протяжении десятилетий. Однако многие люди используют «_bak», «_temp» или «-bak» вместо точки. Это ужасный выбор дизайна; в лучшем случае это ошибка дизайна.

Подождите, значит ли это, что мой сценарий оболочки pull-data.sh никогда не будет выполняться, даже если я добавлю эту команду в crontab: /bin/bash /home/userName/pull-data.sh ?

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

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

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

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

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

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

Это только что заставило меня 1 час возиться/устранять неполадки. Еще более озадачивающим, если вы не знаете о проблеме, является то, что скрипт будет запускаться вручную просто отлично, если вы используете типичную оболочку bash , но не cron . Спасибо!

Давным-давно я столкнулся с чем-то связанным: источник команды находится в bash, а не в sh. В cron/sh используйте точку: . envfile, а не исходный envfile .

@Clockwork sh "mycommand" указывает sh запустить mycommand как файл сценария. Вы имели в виду sh -c "mycommand" ? В любом случае, этот ответ, похоже, касается запуска команды именно в bash, так почему вы добавили сюда команду для sh?

@Olorin Насколько я понимаю, цель первого пункта состояла в том, чтобы попытаться запустить его с помощью sh, чтобы увидеть, действительно ли проблема возникла из-за того, что cron запускает его с помощью sh вместо bash. Опять же, я мало разбираюсь в этом вопросе, поэтому могу ошибаться.

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

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

О, ради бога, убил на это часы. Попытка перезапустить службу после * * * * * touch /tmp/cronworks ничего не дала, но в cronlog есть RELOAD.

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

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

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

Бззз. вам НЕ нужно определять ПУТЬ - здесь лучше всего использовать абсолютные пути. «потому что исполняемый файл может находиться в другом месте на каком-то другом компьютере» не имеет козыря «я хочу, чтобы он запускал именно эту программу, а не какую-то другую, которую кто-то поместил в путь перед моей исходной программой»

да, это было для меня, вне cron я мог запустить команду напрямую, внутри cron мне нужен был полный /usr/bin/любой путь

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

Именно из-за этого моя работа Cron не удалась на прошлой неделе. Наконец-то выяснилось, что у моей даты не было escape-символа (обратная косая черта для всех, кто ищет, что такое escape-символ). Ура!

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

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

Это не уникально для cron , и его легко отследить, просто попытавшись выполнить /path/to/script из командной строки.

Если вы привыкли выполнять сценарии с расширением . scriptname или sh scriptname или bash scriptname , тогда это становится проблемой, специфичной для cron.

Возможно также, что срок действия пароля пользователя истек. Даже пароль 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, появляются в файле системного журнала. Можно использовать

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

У меня Debian (хриплый), но нет /etc/init.d/rsyslog, только inetutils-syslogd и sysklogd. Мне нужно что-то установить или просто перезапустить один из двух?

Если ваше задание cron вызывает приложения с графическим интерфейсом, вам нужно указать им, какой DISPLAY им следует использовать.

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

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

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

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

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

Сначала я сам разобрался, а потом нашел твой ответ! Все равно большое спасибо! В моем случае я отменил/восстановил некоторые crontabs в /var/spool/cron/crontabs через SVN, что изменило его разрешения!

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

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

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

Сценарий чувствителен к местоположению. Это связано с тем, что в скрипте всегда используются абсолютные пути, но не совсем то же самое. Вашему заданию cron может потребоваться перейти в определенный каталог перед запуском, например. задача 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 :

Если скрипт, запускаемый из cron, написан на интерпретируемом языке, таком как PHP, вам может потребоваться установить рабочий каталог в самом скрипте. Например, в PHP: chdir(имя_каталога(__FILE__));

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

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

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

В системных crontab-файлах есть дополнительное поле "пользователь" прямо перед командой для запуска.

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

И наоборот, cron будет выдавать ошибки, например, /usr/bin/restartxyz не является допустимым именем пользователя или подобные, когда происходит обратное.

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

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

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

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

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

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