Почему не работает crontab linux

Почему мой 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

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

Источник

Подскажите, почему не отрабатывает скрипт в crontab

Добрый день. Есть один скрипт recycle_clean.sh, он запускается вручную успешно и отрабатывает, но вот в /etc/crontab есть такая запись:

И из него почему-то не отрабатывает этот скрипт. Cron вроде запущен, по /etc/init.d/cron status выдает:

Стало быть крон запущен. Подскажите, почему не отрабатывает?

ls -l /root/scripts/recycle_clean.sh
head /root/scripts/recycle_clean.sh

Выложи содержимое скрипта и syslog в момент запуска кроном.

Вангую отсутствие PATH

и пустую строку в конце не забудьте.

Это группа, в ней доменные пользователи. А так, как вы предложили (* * * * *), он же не будет отрабатывать раз в сутки, или будет?

У меня нет такого лога даже: /var/log/crond.log

и пустую строку в конце не забудьте

старообрядцы в треде

Это группа, в ней доменные пользователи. А так, как вы предложили (* * * * *), он же не будет отрабатывать раз в сутки, или будет?

он будет отрабатывать 1440 раз в сутки. Каждую минуту. Ускоряет поиск ошибки в 1440 раз.

Да, таких групп не бывает в Linux’е.

У меня нет такого лога даже: /var/log/crond.log

а что, починили, да? Я не в курсе, vim подставляет самостоятельно. Но может ТС notepad.exe юзает?

Честно говоря, вообще никогда не встречал этой проблемы в реальности, и всегда думал что crontab -e сам всё валидирует и делает, хоть добавляй, хоть не добавляй
Я по мотивам какого-то треда пару лет назад тестировал это и всё работало при любом варианте

А чтобы раз в сутки нужно оставить как было:

Так как там достаточно много данных перемещает скрипт, каждую минуту не успеет.

Честно говоря, вообще никогда не встречал этой проблемы в реальности, и всегда думал что crontab -e сам всё валидирует и делает, хоть добавляй, хоть не добавляй

crontab -e вызывает EDITOR, а уж что делает $EDITOR — я не знаю. У меня это vim. А вот народ ставил mcedit, и жаловался на эту проблему.

Я по мотивам какого-то треда пару лет назад тестировал это и всё работало при любом варианте

строка должна заканчиваться \n, иначе это формально не строка, а мусор. Gcc предупреждает, но компиллит. А вот как сейчас crond — я не знаю.

А чтобы раз в сутки нужно оставить как было:

там можно и это, и любое другое валидное время поставить. Сначала минуты, а потом часы. Лучше ставить на пару минут вперёд, что-бы ждать две минуты.

То есть он не отрабатывает потому что не добавлен в

а после создания такого файла и добавления в него строки, аналогичной таковой в /etc/crontab будет автоматически отрабатывать?

То есть он не отрабатывает потому что не добавлен

не. Ты даже НЕ ЗНАЕШЬ, отрабатывается он, или нет. И если нет — то почему. А в том файле это будет написано.

/var/log/crond.log а после создания такого файла

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

и в /var/log/crond.log появилось:

bash: 59: команда не найдена

задумайся, почему именно 59?

echo нужно в начале?

эту строчку в crontab надо вставлять. В консоль вставляй БЕЗ 59 23 * * * root

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

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

PATH проверил, все вроде ок в ней.

Спасибо! Она мне не помешает! =) Показал другому одмину — говорит что сам крон не работает, а crontab в порядке. Но вроде показывает:

mv: невозможно переместить «/var/share/data_drive/Disk_S/.recycled/current» в «/var/share/data_drive/Disk_S/.recycled/2014-03-05/current»: Кат$

видимо «каталог существует»

mkdir: невозможно создать каталог «/var/share/data_drive/Disk_S/.recycled/current»: Файл существует

надо проверить, потом создавать

[ -d /var/share/data_drive/Disk_S/.recycled/current ] || mkdir /var/share/data_drive/Disk_S/.recycled/current

у вас в самом скрипте ошибки.

Пусть уволится, он не админ.

Да, это после того как я вручную запустил его (скрипт), каталог создался, и при последующем запуске тоже вручную выдалась такая ошибка, так как каталог был. Я его удалил. Но кронтаб все равно не работает, не понимаю почему.

У нас просто все неспешно. =)

Сейчас содержимое /etc/crontab такое:

Но кронтаб все равно не работает, не понимаю почему.

1. исправьте ошибки в скрипте. Вот что вы мне моск полоскаете? У меня сын первоклашка, у него есть работа над ошибками. У вас какая-то альтернативная школа?

2. заведомо рабочий скрипт пропишите в crontab. Потом читайте логи.

Checking periodic command scheduler. done (running).

и что? Да, работает чего-то. У меня куча таких шедулеров. Тоже работают. Что дальше?

Да вот даже простой скрипт

* * * * * root echo ‘Время: ‘ ; date

КУДА он должен его «выполнять»? Откуда он знает, что вы эмулятор терминала где-то внутри Xorg’а запустили?

Команда выполняется, а результата ты тупо НЕ ВИДИШЬ.

SHELL=/bin/bash же указан

блжад. Это то, ЧТО выполняет. А КУДА?

Обычно по дефолту оно в почту срёт. А у тебя MAILTO=. Что значит — в никуда.

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

А emulek должен получать молоко за вредность.

Вот попробовал на машине с точно таким же шестым дебианом —

И файл создался. А на моем злосчастном серваке — тишина при точно такой же строке.

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

А emulek’у я очень благодарен.

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

Увы. С тех пор, как изобрели гугл, это обычная ситуация.

А на моем злосчастном серваке — тишина при точно такой же строке.

дык сделай логгирование, как я выше писал. Должно работать.

Да, куда ты прописываешь-то? И как?

Я просто в /etc/crontab прописал ниже под всем, ну команду touch на другой машине с аналогичным дебианом. А вот на этом серваке — тоже добавил. И не отрабатывает. Крон вроде везде одинаковый. Может его переставить? Просто не хотелось бы перезапускать этот сервак. Но просто перезапуск крона не помогает.

думаешь мне интересно, через какую жопу ты делаешь? Нет.

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

Во-первых, если скрипт при повторном запуске без изменения входных данных может обломаться, то это плохой скрипт: http://ru.wikipedia.org/wiki/Идемпотентность

Во-вторых, настройте почтовую подсистему (достаточно взять какой-нибудь nullmailer, чтобы слал через smtp) и настройте перенаправление почты root-а к себе на ящик (ну, или локально складывать, если на машине нет интернета/доступа к какому-нибудь smtp-серверу). Это будет полезно не только для отладки cron, но и для получения информации по многим системным событиям (smartd руту пишет, например, когда на дисках происходит что-то нехорошее).

В-третьих, чтобы закончить бессмысленные аргументы на тему того, что «cron не работает», посмотрите /var/log/syslog. Там будут строчки типа:

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

Источник