1. Главная страница » Компьютеры »

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

Автор: | 16.12.2019

здравствуйте, возникла необходимость использовать крон для своего сайта, до этого я дело с ним не имел, поэтому разбираюсь я в этом довольно плохо

кое как у меня получилось настроить crontab для ежеминутного выполнения get запроса на php файл

вот собственно сам код

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

то есть если помимо первой строки, есть ещё какая то строка (хоть даже пустая), то всё работает, если 1 задача — то нет, и никаких ошибок в логах крона нет, что за бред? спасибо

2 ответа 2

TL;DR: Это не баг, а фича (c)

cron requires that each entry in a crontab end in a newline character. If the last entry in a crontab is missing a newline (ie, terminated by EOF), cron will consider the crontab (at least partially) broken. A warning will be written to syslog.

Что так и означает, что каждая запись в файле crontab должна оканчиваться символом перевода строки, в т.ч. и последняя. В противном случае cron игнорирует её и записывает предупреждение в системный журнал. Прочитать его можно командой tail /var/log/syslog .

Стоит заметить, что парсер crontab, используемый в systemd, лишён такой проблемы.

Последняя строка
Даже в современных изданиях ОС UNIX и Linux отсутствие перевода строки в конце системных конфигурационных файлов приводит к тому, что последняя строка не учитывается, а казалось бы правильно составленный файл не работает, представляясь головоломкой для пользователя, не предупреждённого об этой самобытной особенности.

«нормальные» редакторы всегда вставляют в конец файла символ lf (line feed, оно же
, шестнадцатиричное значение 0a ).

если вы не уверены в используемом редакторе (в частности, например, если используете для редактирования файла какой-нибудь веб-интерфейс вместо редактора), вставляйте этот символ «руками»: переместите курсор в конец последней строки и нажмите enter .

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

  1. неправильная нотация crontab
  2. проблема с правами доступа
  3. переменные среды

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

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

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

30 ответов

Разная среда

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Попробуйте запустить команду в sh , чтобы увидеть, работает ли она
  • Обмотайте команду в подоболочке bash, чтобы убедиться, что она запущена в bash:
    bash -c "mybashcommand"
  • Сообщите cron, чтобы запустить все команды в bash, установив оболочку в верхней части вашего crontab:
    SHELL=/bin/bash
  • Если команда является скриптом, убедитесь, что скрипт содержит shebang:
    #!/bin/bash
Читайте также:  Arduino uno r3 робот

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

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

Это и другие хорошие результаты здесь:
Ссылка

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

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

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

Возможно также, что пароль пользователя истек. Даже пароль root может истек. Вы можете tail -f /var/log/cron.log , и вы увидите cron fail с истекшим паролем. Вы можете установить, чтобы пароль никогда не истекал, выполнив следующее: passwd -x -1

В некоторых системах (Debian, Ubuntu) регистрация cron по умолчанию не включена. В /etc/rsyslog.conf или /etc/rsyslog.d/50-default.conf строка:

должен быть отредактирован ( sudo nano /etc/rsyslog.conf ) раскомментирован на:

После этого вам нужно перезапустить rsyslog через

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В crontabs системы есть дополнительное поле «пользователь» прямо перед командой для запуска.

Это приведет к ошибкам, указывающим на такие вещи, как george; command not found , когда вы перемещаете команду из /etc/crontab или файл в /etc/cron.d в файл crontab пользователя.

И наоборот, cron выдаст ошибки, такие как /usr/bin/restartxyz is not a valid username или аналогичные при обратном.

Сценарий cron вызывает команду с опцией —verbose

У меня был скрипт cron, потому что я был в автопилоте, набирая скрипт, и я включил опцию —verbose:

Скрипт отлично работает при выполнении из оболочки, но не работает при запуске crontab, потому что подробный вывод идет на stdout при запуске из оболочки, но нигде не запускается crontab. Легко исправить удаление ‘v’:

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

Читайте также:  Epson l350 мигает индикатор с каплей

/ bin. Он прокомментирован и заканчивается линией # EOF . Это ежедневно перезагружается из записи crontab, например:

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

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

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

Системным администраторам, да и обычным пользователям часто приходится автоматизировать различные задачи по обслуживанию и работе с Linux с помощью скриптов. Это очень удобно, вы просто запускаете скрипт, и он делает все что необходимо без вашего вмешательства. Следующий шаг в этом пути — настроить автоматически запуск нужного скрипта в нужное время.

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

Как работает Cron?

Фактически, Cron — это сервис, как и большинство других сервисов Linux, он запускается при старте системы и работает в фоновом режиме. Его основная задача выполнять нужные процессы в нужное время. Существует несколько конфигурационных файлов, из которых он берет информацию о том что и когда нужно выполнять. Сервис открывает файл /etc/crontab, в котором указаны все нужные данные. Часто, в современных дистрибутивах там прописан запуск утилиты run-parts, которая запускает нужные скрипты из следующих папок:

  • /etc/cron.minutely — каждую минуту;
  • /etc/cron.hourly — каждый час;
  • /etc/cron.daily — каждый день;
  • /etc/cron.weekly — каждую неделю;
  • /etc/cron.monthly — каждый месяц.

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

Она позволяет выполнять их даже если компьютер работает не всегда и время от времени выключается. Дата выполнения задания последний раз записывается в файл /var/spool/anacron, а затем, при следующем запуске anacron проверяет был ли запущен нужный процесс в нужное время, и если нет, то запускает его. Сам же сервис cron больше рассчитан на выполнение задач в течение дня или с точно расписанным временем и датой.

Настройка Cron

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

Ее всегда желательно выполнять с опцией -e, тогда для редактирования правил будет использован ваш текстовый редактор по умолчанию. Команда открывает вам временный файл, в котором уже представлены все текущие правила cron и вы можете добавить новые. После завершения работы команды cron файл будет обработан и все правила будут добавлены в /var/spool/cron/crontabs/имя_пользователя причем добавленные процессы будут запускаться именно от того пользователя, от которого вы их добавляли.

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

Синтаксис crontab

Как я уже говорил, время задается особым синтаксисом, давайте рассмотрим синтаксис настройки одной задачи cron:

минута час день месяц день_недели /путь/к/исполняемому/файлу

Нужно сказать, что обязательно нужно писать полный путь к команде, потому что для команд, запускаемых от имени cron переменная среды PATH будет отличаться, и сервис просто не сможет найти вашу команду. Это вторая самая распространенная причина проблем с Cron. Дата и время указываются с помощью цифр или символа ‘*’. Этот символ означает, что нужно выполнять каждый раз, если в первом поле — то каждую минуту и так далее. Ну а теперь перейдем к примерам.

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

Сначала можно посмотреть задачи cron для суперпользователя, для этого можно воспользоваться опцией -l:

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

Вы можете удалить все существующие задачи командой -r:

Давайте предположим, что нам нужно запускать от имени суперпользователя наш скрипт по адресу /usr/local/bin/serve. Какой-нибудь обслуживающий скрипт. Самый простой пример — запускать его каждую минуту:

Читайте также:  Gmail com поиск телефона

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

Далее, усложним, будем запускать каждый час, в нулевую минуту:

Запускаем в нулевую минуту нулевого часа, каждый день, это в 12 ночи:

0 0 * * * /usr/local/bin/serve

Если идти так дальше, то можно запускать в первый день каждого месяца:

0 0 1 * * /usr/local/bin/serve

Можно в любой день, например, 15 числа:

0 0 15 * * /usr/local/bin/serve

В первый день недели первого месяца года, 0 часов 0 минут:

0 0 * 1 0 /usr/local/bin/serve

Или в нулевой день недели каждого месяца:

0 0 * * 0 /usr/local/bin/serve

Вы можете выбрать любую минуту, час и день недели, например, 15.30 во вторник:

30 15 * * 2 /usr/local/bin/serve

Понедельник считается первым днем, воскресенье — это седьмой или нулевой день. Еще можно писать сокращенное название дня недели, например sun — воскресенье:

30 15 * * sun /usr/local/bin/serve

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

0 7-19 * * * /usr/local/bin/serve

Если нужно запустить команду несколько раз, можно использовать разделитель ",". Например, запустим скрипт в 5 и 35 минут пятого (16:05 и 16:35), каждый день:

5,35 16 * * * /usr/local/bin/serve

Вы можете захотеть не указывать отдельно время, а просто указать интервал, с которым нужно запускать скрипт, например, раз в 10 минут. Для этого используется разделитель косая черта — "/":

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

  • @reboot — при загрузке, только один раз;
  • @yearly, @annually — раз год;
  • @monthly — раз в месяц;
  • @weekly — раз в неделю;
  • @daily, @midnight — каждый день;
  • @hourly — каждый час.

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

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

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

sudo vi /etc/corn.daily/basckup

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

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

Отладка работы

После того как вы настроили правила, еще хотелось бы проверить работают ли они. Для этого ждем того времени, когда скрипт уже должен быть выполнен и смотрим лог cron. Иногда он находится в /var/log/cron, а иногда пишется в syslog. Например, у меня в crontab есть такая строка:

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

Она должна выполняться в 19.40 каждый день, теперь смотрим лог:

grep CRON /var/log/syslog

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

И видим что в нашем логе она действительно есть и выполняется целиком успешно. Если бы были какие-либо ошибки, то тут же было бы выведено сообщение.

Если нужно проверить скрипт, который находится в одной из специализированных папок, то тут еще проще, просто запустите run-paths, передав ей в параметр нужную папку или даже сам скрипт:

sudo run-paths /etc/cron.daily/

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

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

Выводы

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

Нет похожих записей

Оцените статью:

Об авторе

Основатель и администратор сайта losst.ru, увлекаюсь открытым программным обеспечением и операционной системой Linux. В качестве основной ОС сейчас использую Ubuntu. Кроме Linux интересуюсь всем, что связано с информационными технологиями и современной наукой.

11 комментариев

опечатка в слове cron sudo vi /etc/corn.daily/basckup

Здесь тоже опечатка sudo run-paths /etc/cron.daily/
Нужно run-parts

Может подскажет кто, в чём проблема? Есть скрипт, который содержит команду badblocks. Запускается в ручном режиме и нормально отрабатывает. Загоняю его в crontab -e 30 12 * * * /programs/scripts/badblocks.sh он запускается, но потом пишет sh: line 3: badblocks: команда не найдена.
И вот как это понимать.

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

Можно еще отправлять результат работы скрипта на почту указав команду
MAILTO=user@email.ru

Для себя записываю 🙂
Нужно проверять работает ли сервис и если упал запускать заново

вообще строка выглядит так:
test "$(systemctl is-active zoneminder)" = "inactive"; echo $?
при запущенном сервисе выдает 1, при остановленном — 0
Здесь 0 это true

в crontab чтобы проверялось каждую минуту пишем:
*/1 * * * * root test "$(systemctl is-active zoneminder)" = "inactive" && service zoneminder restart

здравствуйте!
спасибо за статью!
объясните пожалуйста, зачем тут писать путь- "@hourly /usr/local/bin/serve" если и так указано что запускать надо из папки "hourly"
и еще, что такое "serve", это папка или файл?

serve — это пример, вместо него должен быть исполняемый скрипт (файл). Переменную @hourly надо использовать в crontab -e, если использовать папку, то её не надо (в папку нужно только поместить сам скрипт или ссылку на него).

Здравствуйте,мне надо запускать скрипт rebootsv каждую минуту.
Я записал через crontab -e вот так:
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

(Изначально файл был пуст)
Файл сохранил.
Но почему то у меня не чего не работает,помогите мне пожалуста.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *