Cron linux не запускает скрипт

как узнать почему не выполняется скрипт в cron

Добрый день. Добавил в крон скрипт для архивации некоторых папок с ограниченным доступом. Если указываю root пользователем для запуска — все работает. Указываю другого, который так же имеет доступ к папкам — не работает. В логе крона указано, что задание было запущено. В /var/log/messages ничего нет. Как узнать, почему задание не отрабатывает?

Сообщение об ошибках уходят юзеру (в локальную почту), от крона которого запускают скрипт. Можешь глянуть в что-то типа /var/spool/mail или просто запустить mutt (от нужного юзера).

Но быть может скрипт просто подвисает в ожидании чего-то (как вариант)? В процессах его нигде не видно?

В почте смотрел — ничего нет. В процессах скрипт тоже не висит.

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

ошибка в абсолютном/относительном пути к файлу запуска

А вы из под этого юзера пытались скрипт запускать?

как узнать почему не выполняется скрипт в cron

Использовать логирование и отладку.

Если при запуске через шелл работает, а через крон нет, то может быть связано с переменной окружения $PATH. А вообще, да, логгирование в помощь.

Капитан очевидность вангует на кофейной гуще: у рута стоит /bin/bash интерпретатором, а у юзера — /bin/sh, а скрипт использует фичи баша и фейлится при их отсутствии в sh.

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

Во первых входит ли пользователь в группу sudo? Во вторых есть ли файл /etc/cron.allow и прописан ли там пользователь?

Как узнать, почему задание не отрабатывает?

Попробуйте дописать перенаправление вывода в ваш лог файл

Спасибо. Ваш совет помог разобраться. Дело было в правах доступа к папкам со скриптом. Кстати, есть ли какие-то рекомендуемые места в системе для хранения скриптов, доступные всем юзерам?

Кстати, есть ли какие-то рекомендуемые места в системе для хранения скриптов, доступные всем юзерам?

Источник

Почему мой crontab не работает, и как я могу его устранить?

Это Канонический вопрос об использовании cron & кронтаб.

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

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

5 ответов

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

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

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

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

Команда crontab представлена ​​одной строкой. Вы не можете использовать \ для расширения команды на несколько строк. Символ hash ( # ) представляет комментарий, который означает, что все, что на этой строке, игнорируется cron. Ведущие пробелы и пустые строки игнорируются.

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

• Убедитесь, что имя файла не имеет расширения, см. части запуска
• Убедитесь, что у файла есть разрешения на выполнение.
• Сообщите системе, что использовать при выполнении вашего скрипта (например, put #! /bin /sh наверху)

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

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

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

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

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

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

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

(имя пользователя) 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

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

Источник