Cron не видит файл

Обновлено: 06.07.2024

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

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

Другая среда

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

Распространенная "гоча" здесь PATH Переменная окружения отличается. Может быть, ваш скрипт cron использует команду somecommand нашел в /opt/someApp/bin , который вы добавили в PATH в /etc/environment ? Крон игнорирует PATH из этого файла, так что бег somecommand из вашего скрипта не получится при запуске с cron, но сработает при запуске в терминале. Стоит отметить, что переменные из /etc/environment будут переданы заданиям cron, но не переменным, которые специально устанавливает сам cron, таким как PATH ,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если ваш 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/<user>/scripts/session-purge.sh

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

Формат спецификации задания 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:

Самая частая причина, по которой я видел сбой cron в неверно указанном расписании. Требуется практика, чтобы указать работу, запланированную на 23:15 как 30 23 * * * вместо * * 11 15 * или же 11 15 * * * , День недели для рабочих мест после полуночи также сбивается с толку 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.

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

Как его победить?

А у вас часом не мультисайтинг?
Файл cron.php должен быть в корне сайта или мультисайтинга.
Иначе в нем нужно четко прописать пути к файлам, которые включаются через include

Мультисайтинг - имеется ввиду со стороны друпала? Или со стороны хостинга?
В моем случае - свежеустановленный друпал.
cron.php лежит именно в корне сайта, вместе с index.php и пр.

Крон прекратил ругаться, но, в тоже время и не выполняет никаких действий.

Но каталог в котором запущен крон не корневой. Поэтому не находятся другие включаемые файлы.

У меня на хостинге во все кроны пришлось дописать функцию chdir - попробуй.

А не мог бы ты кинуть мылом правленый файл крона, потому как в PHP не силен и какие параметры подставлять этой функции не въеду
мой ящик: provin собака inbox ру

Мой файл тебе не поможет. Он хостингозависимый. В начале файла добавь строку

<?php
chdir ( "полный/путь/от/корня/сервера/твоего/провайдера/до/корня/твоего/сайта" );
?>

Может кому актуально будет, вот работающее решение:

дальше в кроне запускаешь
* * * * * /some_path/run.sh some_script.php
------------ cut here -----------
(C) TYMAH

ЗЫ Просьба ногами не пинать, если боян

Ваша финансовая помощь дает нам возможность оплачивать хостинг и поддерживать стабильную работу сайта. Благодарим за поддержку!

Трекер

Встречайте Backdrop CMS - форк друпала.

Drupal 7 как поднять описание на странице?

Drupal 7 Views фильтрация по категории Пользователя

Поиск не находит слова с чёрточками. Д7

Написать ссылку в Ячейку таблицы в tableselect ? Д8

Упали сайты на NIC

D7 - D9 нормально апгрейдится?

docker4drupal - а как создать 2 БД на одном проекте? Или оффтоп: способ миграции D7-D8.

docker4drupal как сделать экспорт и импорт БД без drush?

Карта от Google и pagespeed.

Новые материалы

Drupal 7 как поднять описание на странице?

Поиск не находит слова с чёрточками. Д7

Написать ссылку в Ячейку таблицы в tableselect ? Д8

Упали сайты на NIC

D7 - D9 нормально апгрейдится?

Drupal 7 Views фильтрация по категории Пользователя

docker4drupal - а как создать 2 БД на одном проекте? Или оффтоп: способ миграции D7-D8.

Одобрение регистрации пользователя

Подтверждение домена для изготовления SSL-сертификата

Поиск внутри списка Нод. Д7.

Содержимое сайта публикуется на условиях CreativeCommons Attribution-ShareAlike 3.0 или более поздней версии. Программные коды в тексте статей — на условиях GNU GPL v2 или более поздней версии.

Что-то нужно сделать, чтобы активировать конкретный crontab или активировать «службу» cron сам по себе?

Что если он работает и завершается с ошибкой, которую вы не видите, потому что перенаправляете весь вывод в / dev / null? :) @tink можно ли вместо этого добавить вывод в конец файла? уверенный; 0,15,30,45 * * * * /backup.sh >> / tmp / testing_cron.out 2> & 1 @Jivan, просто небольшая заметка: ls /etc/cron.d эквивалентно с cd /etc/cron.d && ls точки зрения производства. Разница лишь в том, что рабочий каталог не изменится.

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

Вы также должны убедиться, что права доступа и владелец: группа установлены правильно ( -rw-r--r-- и принадлежат root:root )

crontab -l отчеты о записях cron в /var/spool/cron/crontabs/ - т.е. crontabs на пользователя . /etc/cron.d файлы являются системными crontabs и не сообщаются crontab -l . На самом деле я упомянул, что это не работает, но я только что понял, что это после добавления root в файл - просто crontab -l не упомянул об этом, как вы объяснили почему - спасибо за вашу помощь кажется, что имя файла также играет роль. В моем случае я добавил etc/cron.d файл с точкой в середине имени, и задание так и не было выполнено, пока я его не переименовал та же проблема здесь, тире "-" в имени файла, изменение их на подчеркивания "_" решили проблему, задания выполнялись немедленно. У меня тоже была тире . что за . почему ?! В любом случае, спасибо @Rob

Еще я заметил, что файл /etc/cron.d не может иметь расширение. В моем конкретном случае у меня была символическая ссылка:

Это верно в Ubuntu (возможно, во всех дистрибутивах, производных от Debian). В Amazon Linux (и, возможно, во всех дистрибутивах, созданных на Redhat), у вас может быть точка в имени файла. Спасибо Unix.SE. Я только что проверил чистый Debian, и точки там тоже не работают. Тире работают (в отличие от того, что написано выше).

Я думаю, что вы, вероятно, просто пропустили необходимую пустую строку в конце вашего файла cron. У меня была та же проблема, но после проверки всего перечисленного здесь (пользовательские права, имя файла, версия cron и т. Д.) Я понял, что после последней записи в моем /etc/cron.d/own_cron файле не было разрыва строки, и это приводит к игнорированию всего файла.

Если вы единственный пользователь на этом компьютере, вы можете использовать только crontab -e . Вам будет предложено выбрать редактор при первом запуске команды. Затем вы можете добавить это к нему:

Если вы переключитесь на учетную запись обычного пользователя, вам нужно будет использовать sudo crontab -e для настройки сценариев, которые вы хотите запускать по расписанию root .

crontab -l отображает только текущий crontab, как только вы настроите его с помощью crontab -e . Если у вас есть файл cron в /etc/cron.d /, он не будет отображаться с crontab -l .

Вы также должны убедиться , что ваш скрипт исполняемым: chmod +x /backup.sh .

спасибо - в этом случае crontab установлен в контексте, Dockerfile так что я не могу этого сделать crontab -e - но в любом случае это полезная информация

Для Cron из * bian distros (например, Raspbian) вам нужно включить -l параметр демона Cron. Это целесообразно сделать с помощью /etc/default/cron конфигурационного файла, включив EXTRA_OPTS .

Это было опровергнуто, но в некоторых случаях оно является правильным, хотя и не объяснено. В дистрибутивах на основе Debian -l опция для демона cron авторизует расширенный набор имен файлов в /etc/cron.d каталоге, поэтому, если файл игнорируется, поскольку в нем есть точка, то либо «добавление -l», либо «удаление точки» исправит проблему.

Проверьте вашу версию cron .

Кажется, что если вы используете crond Диллона, вам не нужен пользователь в /etc/cron.d записи.

Я понял это после того, как чуть не выдернул оставшиеся волосы.

У меня есть несколько записей, которые были /etc/cron.d добавлены различными установками. После некоторого расследования я обнаружил, что один из них работает. У него не было пользователя. Таким образом, я взял пользователя из других. И они начали работать.

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

Cron не видит файл

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

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

Комментарии

Трекер

Встречайте Backdrop CMS - форк друпала.

Drupal 7 как поднять описание на странице?

Drupal 7 Views фильтрация по категории Пользователя

Поиск не находит слова с чёрточками. Д7

Написать ссылку в Ячейку таблицы в tableselect ? Д8

Упали сайты на NIC

D7 - D9 нормально апгрейдится?

docker4drupal - а как создать 2 БД на одном проекте? Или оффтоп: способ миграции D7-D8.

docker4drupal как сделать экспорт и импорт БД без drush?

Карта от Google и pagespeed.

Новые материалы

Drupal 7 как поднять описание на странице?

Поиск не находит слова с чёрточками. Д7

Написать ссылку в Ячейку таблицы в tableselect ? Д8

Упали сайты на NIC

D7 - D9 нормально апгрейдится?

Drupal 7 Views фильтрация по категории Пользователя

docker4drupal - а как создать 2 БД на одном проекте? Или оффтоп: способ миграции D7-D8.

Одобрение регистрации пользователя

Подтверждение домена для изготовления SSL-сертификата

Поиск внутри списка Нод. Д7.