Crontab не работает ubuntu

Обновлено: 02.07.2024

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

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

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

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

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, как сформулировать команду:

Будьте ОЧЕНЬ осторожны при использовании знака процента ( % ) в вашей команде. Если они не экранированы \% , они преобразуются в новые строки, и все после первого неэкранированного % передается вашей команде на 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. и он не запускает

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

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

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

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

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

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

(имя пользователя) 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
проблема с разрешениями
переменные среды

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

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

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

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

Другая среда

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. Например

Я думаю, что я просто влюбился в это, и новая строка в конце . двойной удар. +1 env , я совершенно забыл об этой команде и подумал, что PATH работает. На самом деле в моем случае все было по-другому. @pbr Если такие каталоги доступны для записи другим, система уже взломана.

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

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

это такой демонстратор, почему он не был исправлен за столько лет cron? Кажется, исправлено в Vixie cron: man crontab в Ubuntu 10.10 говорится: «cron требует, чтобы каждая запись в crontab заканчивалась символом новой строки. Если в последней записи в crontab отсутствует символ новой строки, cron будет считать crontab (по крайней мере, частично) неработающим. и отказаться от его установки. " (И дата в конце 19 апреля 2010 года.) @barraponto На самом деле это ошибка в новых текстовых редакторах. Символ «новой строки» должен быть символом завершения строки , поэтому последняя строка в текстовом файле должна заканчиваться символом новой строки, который не отображается в редакторе. Vi и vim правильно используют этот символ, а cron был создан до того, как новые редакторы начали свое странное поведение . Следовательно, воспроизводим его, сохраняя и включая пустую строку. Если вы редактируете crontab, используя crontab -e его, проверьте синтаксис файла перед разрешением сохранения, включая проверку на новую строку. @ Chan-HoSuh, согласно man-странице "cron требует, чтобы каждая запись в crontab заканчивалась символом новой строки. Если в последней записи в crontab отсутствует символ новой строки, cron будет считать crontab (по крайней мере, частично) сломанным и откажется установить его. " Это поведение будет вызываться при редактировании, а затем при сохранении файла crontab с использованием этой -e опции, и не зависит от редактора.

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

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

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

РЕДАКТИРОВАТЬ: Также вы можете использовать systemctl в современном Linux, например,

Спасибо за показ мне pgrep. Я продолжал делать ps -ef | grep foo Вы также можете использовать, pidof cron что будет опускать результаты для других приложений, которые также имеют слово «cron», например, crontab. Странно, все это не дает мне ничего, чтобы показать, что cron работает, но если я бегу, sudo service cron start я получаю start: Job is already running: cron

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

Смотрите run-parts (8):

Итак, если у вас есть cron-скрипт backup.sh , analyze-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 вместо точки. Это ужасный выбор дизайна; в лучшем случае это ошибка дизайна.

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

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

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

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

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

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

предложение bash очень полезно, исправлена проблема с моим cron. Это просто вызвало у меня 1 час возни / проблем. Еще более озадачивает, если вы не знаете, в чем проблема, - сценарий будет запускаться вручную просто отлично, если вы используете обычную оболочку bash , но не с cron . Спасибо! Давным-давно я столкнулся с чем-то связанным: команда source в bash, но не sh. В cron / sh используйте точку: . envfile вместо source envfile . @Clockwork sh "mycommand" говорит sh запустить mycommand в виде файла сценария. Вы имели в виду sh -c "mycommand" ? Во всяком случае, этот ответ, похоже, касается запуска команды именно в bash, так почему вы добавили команду sh здесь? @Olorin Насколько я понимаю, целью первого пункта было попытаться запустить его с помощью sh, чтобы увидеть, действительно ли проблема в том, что cron запускает его с помощью sh вместо bash. Опять же, у меня мало знаний об этом, поэтому я могу ошибаться.

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

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

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

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

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

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

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

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

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 через

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

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

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

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

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

aplay нуждался в этом по некоторым причинам. спасибо

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

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

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

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

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

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

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

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

Если скрипт, вызываемый из cron, написан на интерпретируемом языке, таком как PHP, вам может потребоваться установить рабочий каталог в самом скрипте. Например, в PHP: chdir(dirname(__FILE__)); Просто попался с этим: скрипт был в корне моего домашнего каталога, но потом я переместил его (и обновил crontab) и не мог понять, почему он не работает. Оказывается, сценарий использовал относительный путь, предполагая, что он был относительно местоположения сценария, но на самом деле он был относительно корня моего домашнего каталога, потому что это был рабочий каталог, который использовал cron, поэтому сценарий работал , когда он был в корне домашнего каталога (так как ожидается , рабочий каталог скрипта , и это фактическое рабочее просто случилось совпасть).

Спецификации 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:

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

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

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

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

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

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

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

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

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

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

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

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

это такой шоу-шоппер, почему он не исправлен за столь многие годы существования cron? – Capi Etheriel 27 January 2011 в 07:20 Кажется, что исправлено в Vixie cron: man crontab на Ubuntu 10.10 говорит, что «cron требует, чтобы каждая запись в crontab заканчивалась символом новой строки. Если последняя запись в crontab отсутствует в новой строке, cron рассмотрит crontab (по крайней мере частично) и откажется его установить. & Quot; (И дата в конце - 19 апреля 2010 года). – Marius Gedminas 2 February 2011 в 02:58 @barraponto Это на самом деле ошибка в новых текстовых редакторах. «Новая линия» символ должен быть символом окончания окончания строки , поэтому конечная строка в текстовом файле должна заканчиваться символом новой строки, который не отображается в редакторе. Vi и vim правильно используют персонажа, а cron был создан до того, как новые редакторы начали свое странное поведение . Следовательно, воспроизведение его сохраняет и включает пустую строку. – Izkata 18 January 2012 в 21:20 Если вы отредактируете crontab с помощью crontab -e, он проверит синтаксис файла, прежде чем разрешить сохранение, включая проверку новой строки. – Tom Harrison Jr 26 September 2014 в 23:26 @ Chan-HoSuh, согласно man-странице «cron» требует, чтобы каждая запись в crontab заканчивалась символом новой строки. Если последняя запись в crontab отсутствует в новой строке, cron рассмотрит crontab (по крайней мере частично) и откажется его установить. & Quot; Это поведение будет вызываться при редактировании, затем сохранение crontab с использованием опции -e и не зависит от редактора. – Tom Harrison Jr 18 November 2014 в 20:40

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

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

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

ответ дан 4 revs, 4 users 38%user6019 25 May 2018 в 23:19 Спасибо, что показал мне pgrep. Я продолжал делать ps -ef | grep foo – ripper234 17 March 2011 в 21:01 Вы также можете использовать pidof cron, который опускает результаты для других приложений, которые также имеют слово «cron», например, crontab. – Pithikos 11 March 2014 в 22:19 Странно, все это не дает мне ничего, чтобы показать, что cron работает, но если я запустил sudo service cron start, я получаю start: Job is already running: cron – Colleen 6 April 2015 в 20:04 service crond start, если его centos / RHEL – Srihari Karanth 18 January 2017 в 14:02

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

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

Это особенность, а не ошибка - она хранит такие вещи, как myscript.backup или myscript.original или myscript.rpm-new, которые запускаются рядом с myscript. – pbr 9 April 2012 в 03:45 @pbr: имеет смысл. По крайней мере, это было бы полезно для отладки, если run-parts --test (или другая мнимая опция, такая как --debug, выводит файлы, которые она пропускает, включая причину. – Rabarberski 30 May 2013 в 13:46 Если это особенность, это не очень приятно :( Многие люди используют точку в имени файла (наиболее распространенным является backup.sh). Если вы хотите, чтобы скрипт прекратил выполнение, самым логичным методом будет удалите его из каталога cron.d. – MatuDuke 16 May 2014 в 18:59 Это такая плохая функция, что это ошибка. Обычно принято требовать конкретного окончания (например, «список» или «.cron» или что-то еще), если люди хотят удостовериться, что вещи только запускаются, когда они предназначены. Произвольный выбор точки в качестве вероятного разделителя для ".bak" или ".temp" или что-то еще, совершенно непредсказуемо, за исключением того, что он будет предсказуемо путать людей. Законные окончания, такие как «.sh» и «.pl» широко используются десятилетиями. Многие люди используют «_bak». или "_temp" или "-бак" вместо точки, однако. Это ужасный выбор дизайна; это лучшая проектная ошибка. – Teekin 10 May 2017 в 23:42

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

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

Предложение bash очень полезно, исправлена проблема с моим cron. – Maxim Galushka 19 February 2016 в 02:38 Это просто вызвало у меня 1 час поиска / устранения неполадок. Еще более озадачивая, если вы не знаете о проблеме, скрипт будет работать вручную просто отлично, если вы типичная оболочка bash, но не с cron. Благодаря! – Hendy 22 November 2016 в 23:42 Давно я столкнулся с чем-то связанным: команда source находится в bash, но не sh. В cron / sh используйте период: . envfile, а не source envfile. – kungphu 22 December 2017 в 06:24

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

Да, после изменения часового пояса в системе необходимо либо перезапустить все службы, которые интересуются временем, либо перезагрузкой. Я предпочитаю перезагрузку, чтобы убедиться, что все поймал. – pbr 9 April 2012 в 03:48

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

Это то, что заставило мою работу на Крон провалиться на прошлой неделе. Наконец выяснилось, что моя дата не имела escape-символа (обратная косая черта для любых других людей, которые ищут, каков символ побега). Ура! – Valien 14 October 2013 в 19:27

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

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

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

см. ответ geirha, вы можете (должны) определить cron's PATH – Capi Etheriel 27 January 2011 в 07:22 Bzzt. вам НЕ нужно определять PATH - использование абсолютных путей - лучшая практика здесь. ", поскольку исполняемый файл может быть в другом месте на каком-либо другом компьютере" не trump " Я хочу, чтобы он выполнял именно эту программу, а не какой-то другой, кто вставил путь перед моей исходной программой " – pbr 9 April 2012 в 03:55

Возможно также, что пароль пользователя истек. Даже пароль root может истек. Вы можете tail -f /var/log/cron.log, и вы увидите cron fail с истекшим паролем. Вы можете установить пароль так, чтобы он не заканчивался, выполнив это: 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

ответ дан 6 revs, 5 users 34%unknown 25 May 2018 в 23:19 У меня есть Debian (wheezy), но нет /etc/init.d/rsyslog, только inetutils-syslogd и sysklogd. Должен ли я что-то установить или просто перезапустить один из двух? – hgoebl 21 October 2016 в 14:41

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

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

Если вы используете сценарии с . scriptname или sh scriptname или bash scriptname, это становится проблемой cron. – Eliah Kagan 25 November 2011 в 05:09

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

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

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

По какой-то причине для этого нужен был. Спасибо – IljaBek 2 October 2016 в 13:47

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

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

Обратите внимание: если у вас есть линия crontab, которая настроена на вывод канала в файл, который еще не существует, а каталог для файла - тот, к которому пользователь cron не имеет доступа, тогда строка не будет выполняться. – Evan Donovan 10 September 2015 в 19:51

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

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

Проблема решена с помощью

Сначала я понял это сам, а потом нашел ваш ответ! Еще большое спасибо! В моем случае я вернул / восстановил некоторые crontabs в / var / spool / cron / crontabs через SVN, который изменил его разрешения! – alfonx 9 June 2013 в 01:40

Сценарий чувствителен к местоположению. Это связано с всегда использованием абсолютных путей в скрипте, но не совсем то же самое. Перед запуском вашего задания 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/<user>/scripts/session-purge.sh

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

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

Если скрипт, вызываемый из cron, написан на интерпретируемом языке, таком как PHP, вам может потребоваться установить рабочий каталог в самом скрипте. Например, в PHP: chdir(dirname(__FILE__)); – Evan Donovan 10 September 2015 в 19:14 Просто попался с этим: сценарий был в корне моего домашнего каталога, но затем я переместил его (и обновил crontab) и не мог понять, почему он не работает. Оказывается, скрипт использовал относительный путь, предполагая, что он относился к местоположению скрипта, но он был по существу относительно корня моего домашнего каталога, потому что это был рабочий каталог, который использовал cron, поэтому сценарий работал, когда он был в корне моей домашней директории (потому что ожидаемый рабочий каталог сценария и фактическая работа только совпадали ). – Micheal Johnson 4 February 2016 в 22:36

Спецификации 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 ]

Почему это вызывает провал? Проблемы с буфером? – Adam Matan 31 May 2012 в 11:38

Наиболее частая причина, по которой я видел 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 в

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

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

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

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

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

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

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

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

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

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

Заключение:

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

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

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