cron не выполняет скрипт

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Планировщик cron: не выполняется пользовательский скрипт.?

2. В конкретно вашем случае вы используете системный кронтам, а не пользовательский.

/.bash_history будет относиться к текущему юзеру, который в данном случае будет root
Точно у рута не очищается хистори при ребуте?

upd. Сейчас попробую переместить скрипт в / и запустить.

В кронтабе не пользуйтесь подобными сокращениями и алиасами. Ставь полный путь и убедить в правах доступа.

Где из этого смотреть инфо про путь:
/etc/systemd/system/multi-user.target.wants/anacron.service
/etc/systemd/system/multi-user.target.wants/cron.service
/lib/systemd/system/anacron.service
/lib/systemd/system/cron.service
/var/lib/systemd/deb-systemd-helper-enabled/anacron.service.dsh-also
/var/lib/systemd/deb-systemd-helper-enabled/cron.service.dsh-also
/var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/anacron.service
/var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/cron.service
?

, с самого начала от /

Кому не лень, подскажите pls, в каком файле прописано, что помимо системных заданий демону cron необходимо выполнять также и пользовательские?

в системных кронтабах просто на одну колонку больше
# Minutes Hours Days Months WeekDays USER Command

как это работает с тегами @reboot не подскажу, надо документацию глянуть.
Но от рута всегда можно что-то сделать через su/sudo

Источник

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

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

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

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

46 ответов

Другая среда

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итак, запись в crontab

23 3 * * * /usr/bin/rake db:session_purge RAILS_ENV=production

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

23 3 * * * /home/ /scripts/session-purge.sh

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

Спецификации 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 или подобное, когда происходит обратное.

Сценарий выполнялся нормально при выполнении из оболочки, но не работал при запуске из crontab, поскольку подробный вывод выводится на стандартный вывод при запуске из оболочки, но нигде при запуске из crontab. Легко исправить, чтобы удалить «V»:

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

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

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

Источник

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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»: Файл существует

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

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

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

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

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

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

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

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

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

Checking periodic command scheduler. done (running).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

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

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

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

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

Другая среда

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итак, запись в crontab

23 3 * * * /usr/bin/rake db:session_purge RAILS_ENV=production

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

23 3 * * * /home/ /scripts/session-purge.sh

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

Спецификации 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 или похожие, когда произойдет обратное.

Сценарий выполнялся нормально при выполнении из оболочки, но не работал при запуске из crontab, поскольку подробный вывод выводится на стандартный вывод при запуске из оболочки, но нигде при запуске из crontab. Легко исправить, чтобы удалить «V»:

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

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

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

Источник