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

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

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

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

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

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

442 голоса | спросил 11 revs, 5 users 57%
Adam Matan
1 Jam1000000amThu, 01 Jan 1970 03:00:00 +030070 1970, 03:00:00

30 ответов


426

Разная среда

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

* * * * * env> /tmp/env.output

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

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

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

 #! /bin /bash
PATH = /Opt /someApp /бен: /USR /местные /SBIN: /USR /местные /бен: /USR /SBIN: /USR /бен: /SBIN: /бен

# остаток сценария следует

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

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

 PATH = /opt /someApp /bin: /usr /local /sbin: /usr /local /bin: /usr /sbin: /usr /bin: /SBIN: /бен

15 1 * * * backupscript --incremental /home /root
ответил Antonio 11 Jpm1000000pmThu, 11 Jan 2018 21:51:17 +030018 2018, 21:51:17
284

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

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

Хотя cron требует, чтобы каждая запись в crontab заканчивалась в новой строке
   символа, ни команда crontab, ни демона cron не обнаружат
   эта ошибка. Вместо этого, crontab будет загружаться нормально. Однако,
   команда никогда не будет запущена. Лучший выбор - обеспечить, чтобы ваш
   В конце crontab имеет пустую строку.

   4-е распределение Berkeley 29 декабря 1993 года CRONTAB (1)
ответил Antonio 11 Jpm1000000pmThu, 11 Jan 2018 21:51:17 +030018 2018, 21:51:17
119

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

Тип:

pgrep cron

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

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

sudo service cron start
ответил Antonio 11 Jpm1000000pmThu, 11 Jan 2018 21:51:17 +030018 2018, 21:51:17
81

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

См. run-parts (8):

Если ни параметр --lsbsysinit, ни параметр --regex не указаны, тогда
   имена должны состоять полностью из букв верхнего и нижнего регистра, digâ €
   его, подчеркивания и дефисы.

   Если задана опция -sbsysinit, то имена не должны заканчиваться на
   .dpkg-old или .dpkg-dist или .dpkg-new или .dpkg-tmp и должны принадлежать
   одно или несколько из следующих пространств имен: пространство имен, назначенное LANANA
   (^ [А-z0-9] + $); иерархические и зарезервированные пространства имен LSB
   (? ^ _ ([А-z0-9 _.] + -) + [а-z0-9] + $); и пространство имен скриптов cron для Debian
   (^ [A-Za-Z0-9 _-] + $).

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

ответил Antonio 11 Jpm1000000pmThu, 11 Jan 2018 21:51:17 +030018 2018, 21:51:17
55

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

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

  • Попробуйте запустить команду в sh, чтобы увидеть, работает ли она
  • Оберните команду в bash subshell, чтобы убедиться, что она запускается в bash:
    bash -c "mybashcommand"
  • Сообщите cron, чтобы запустить все команды в bash, установив оболочку в верхней части вашего crontab:
    SHELL = /bin /bash
  • Если команда является скриптом, убедитесь, что скрипт содержит shebang:
    #! /bin /bash
ответил Antonio 11 Jpm1000000pmThu, 11 Jan 2018 21:51:17 +030018 2018, 21:51:17
34

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

sudo service cron restart
ответил Antonio 11 Jpm1000000pmThu, 11 Jan 2018 21:51:17 +030018 2018, 21:51:17
29

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

Это и другие хорошие результаты здесь:
http://www.pantz.org/software/cron /croninfo.html

ответил Antonio 11 Jpm1000000pmThu, 11 Jan 2018 21:51:17 +030018 2018, 21:51:17
27

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

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

# m h dom mon dow command
0 0 * * * /bin /grep ERROR /home/adam/run.log>>> /TMP /ошибки

Вместо:

# m h dom mon dow command
0 0 * * * grep ERROR /home/adam/run.log>> /TMP /ошибки

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

ответил Antonio 11 Jpm1000000pmThu, 11 Jan 2018 21:51:17 +030018 2018, 21:51:17
23

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

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

# cron. * /var/log/cron.log

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

cron. * /var/log/cron.log

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

/etc/init.d/rsyslog restart

или

сервис rsyslog restart

Источник: Включить ведение журнала crontab в Debian Linux

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

cat /var /log /syslog | grep cron

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

ответил Antonio 11 Jpm1000000pmThu, 11 Jan 2018 21:51:17 +030018 2018, 21:51:17
20

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

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

ответил Antonio 11 Jpm1000000pmThu, 11 Jan 2018 21:51:17 +030018 2018, 21:51:17
16

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

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

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

ответил Antonio 11 Jpm1000000pmThu, 11 Jan 2018 21:51:17 +030018 2018, 21:51:17
14

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

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

ответил Antonio 11 Jpm1000000pmThu, 11 Jan 2018 21:51:17 +030018 2018, 21:51:17
13

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

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

sudo service cron restart
grep -i cron /var /log /syslog | tail -2
2013-02-05T03: 47: 49.283841 + 01: 00 ubuntu cron [49906]: (пользователь) INSECURE MODE (ожидается режим 0600) (crontabs /user)

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

# правильное разрешение
sudo chmod 600 /var /spool /cron /crontabs /пользователь
# сигнал-сигнал для перезагрузки файла
sudo touch /var /spool /cron /crontabs
ответил Antonio 11 Jpm1000000pmThu, 11 Jan 2018 21:51:17 +030018 2018, 21:51:17
10

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

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

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

будет лучше, чем

23 3 * * * cd /var /www /production /current & & & /usr /bin /rake db: session_purge RAILS_ENV = производство

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

23 3 * * * /home/<user>/scripts/session-purge.sh

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

cd /var /www /production /current
/usr /bin /rake db: session_purge RAILS_ENV = производство
ответил Antonio 11 Jpm1000000pmThu, 11 Jan 2018 21:51:17 +030018 2018, 21:51:17
10

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

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

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

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

И наоборот, cron выдаст ошибки, такие как /usr /bin /restartxyz не является допустимым именем пользователя или аналогичным при обратном.

ответил Antonio 11 Jpm1000000pmThu, 11 Jan 2018 21:51:17 +030018 2018, 21:51:17
9

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

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

#! /Bin /Баш
некоторые команды
tar cvfz /my/archive/file.tar.gz /my /shared /directory
приходить больше команд

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

#! /Bin /Баш
некоторые команды
tar cfz /my/archive/file.tar.gz /my /shared /directory
еще несколько команд
ответил Antonio 11 Jpm1000000pmThu, 11 Jan 2018 21:51:17 +030018 2018, 21:51:17
7

Наиболее частая причина, по которой я видел 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 в ~ /bin. Он прокомментирован повсюду и заканчивается строкой # EOF. Это ежедневно перезагружается из записи crontab, например:

#! /USR /бен /кронтаб
# Reload this crontab
#
54 12 * * * $ {HOME} /bin /crontab

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

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

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

ответил Antonio 11 Jpm1000000pmThu, 11 Jan 2018 21:51:17 +030018 2018, 21:51:17
6

Если вы получаете доступ к учетной записи через SSH-ключи, вы можете войти в учетную запись, но не заметить, что пароль в учетной записи заблокирован (например, из-за истечения срока действия или недопустимых попыток пароля)

Если система использует PAM, и учетная запись заблокирована, это может остановить работу cronjob. (Я тестировал это на Solaris, но не на Ubuntu)

Вы можете найти такие сообщения в /var /adm /messages:

Oct 24 07:51:00 mybox cron [29024]: [ID 731128 auth.notice] pam_unix_account: cron пытается проверить заблокированную учетную запись myuser с локального хоста
Oct 24 07:52:00 mybox cron [29063]: [ID 731128 auth.notice] pam_unix_account: cron пытается проверить заблокированную учетную запись myuser с локального хоста
Oct 24 07:53:00 mybox cron [29098]: [ID 731128 auth.notice] pam_unix_account: cron пытается проверить заблокированный myuser учетной записи с локального хоста
Oct 24 07:54:00 mybox cron [29527]: [ID 731128 auth.notice] pam_unix_account: cron пытается проверить заблокированную учетную запись myuser с локального хоста

Все, что вам нужно сделать, это запустить:

# passwd -u <USERNAME>

как root, чтобы разблокировать учетную запись, и crontab должен снова работать.

ответил Antonio 11 Jpm1000000pmThu, 11 Jan 2018 21:51:17 +030018 2018, 21:51:17
4

Если у вас есть такая команда:

* * * * * /path /to /script>>> /TMP /вывода

, и он не работает, и вы не можете увидеть какой-либо вывод, это не обязательно означает, что cron не работает. Сценарий может быть сломан, а вывод будет stderr , который не будет передан в /tmp /output. Проверьте, что это не так, путем захвата этого выхода:

* * * * * /path /to /script>>> /tmp /output 2 & 1

, чтобы узнать, поможет ли вам решить вашу проблему.

ответил Antonio 11 Jpm1000000pmThu, 11 Jan 2018 21:51:17 +030018 2018, 21:51:17
3

В моем случае у cron и crontab были разные владельцы.

Не работает. У меня было это:

Пользователь @ Uva ~ $ ps -ef | grep cron | grep -v grep
Пользователь 2940 7284 pty1 19:58:41 /usr /bin /crontab
SYSTEM 11292 636? 22:14:15 /usr /sbin /cro

В основном мне приходилось запускать cron-config и правильно отвечать на вопросы. Есть момент, когда мне нужно было ввести мой пароль пользователя Win7 для моей учетной записи «Пользователь». От чтения, которое я сделал, похоже, что это потенциальная проблема безопасности, но я единственный администратор в одной домашней сети, поэтому я решил, что все в порядке.

Вот последовательность команд, которая заставила меня двигаться:

Пользователь @ Uva ~ $ cron-config
Демон cron может работать как служба или как работа. Последнее не рекомендуется.
Cron уже установлен как служба под учетной записью LocalSystem.
Вы хотите удалить или переустановить его? (да /нет) да
ОК. Служба cron была удалена.

Вы хотите установить демона cron в качестве службы? (да /нет) да
Введите значение CYGWIN для демона: [] ntsec

Вы должны решить, на какой учетной записи будет выполняться демон cron.
Если вы единственный пользователь на этом компьютере, демон может работать как самостоятельно.
   Это дает доступ ко всем сетевым дискам, но позволяет вам только как пользователь.
Чтобы запустить несколько пользователей, cron должен изменить контекст пользователя, не зная
  пароли. Существует три способа сделать это, как объяснено в
  http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-nopasswd1
Если все пользователи cron выполнили «passwd -R» (см. Man passwd),
  который обеспечивает доступ к сетевым дискам, или если вы используете
  cyglsa, тогда cron должен запускаться под учетной записью локальной системы.
В противном случае вам нужно создать или создать привилегированную учетную запись.
  Этот скрипт поможет вам в этом.
Вы хотите, чтобы демон cron работал как вы? (да /нет) нет

Были ли пароли всех пользователей cron сохранены с помощью «passwd -R» или
вы используете пакет cyglsa? (да /нет) нет

Поиск или создание привилегированного пользователя.
Были найдены следующие учетные записи: «cyg_server».
Этот скрипт планирует использовать учетную запись cyg_server.
Вы хотите использовать другое привилегированное имя учетной записи? (да /нет) да
Введите другое имя: Пользователь

Reenter: Пользователь


Пользователь аккаунта уже существует. Проверка его привилегий.
INFO: Пользователь является действительной привилегированной учетной записью.
INFO: имя пользователя cygwin для учетной записи User is User.

Введите пароль для пользователя «Пользователь»:
Повторно введите:
Запуск cron_diagnose ...
... проблем не обнаружено.

Вы хотите запустить демона cron в качестве службы сейчас? (да /нет) да
ОК. Демон cron теперь запущен.

В случае возникновения проблемы просмотрите файл журнала для cron,
/var/log/cron.log и журнал событий Windows (с использованием /usr /bin /cronevents)
для получения информации о проблеме cron.

Изучите также любой файл cron.log в каталоге HOME
(или файл, указанный в MAILTO) и связанные с cron файлы в /tmp.

Если вы не можете исправить эту проблему, сообщите об этом на [email protected]
Запустите сценарий /usr /bin /cronbug и ATTACH его вывод
(файл cronbug.txt) на ваш адрес электронной почты.

ПРЕДУПРЕЖДЕНИЕ: PATH может быть задано по-разному в cron, чем в интерактивных оболочках.
         Названия, такие как «найти» и «дату», могут относиться к программам Windows.


Пользователь @ Uva ~ $ ps -ef | grep cron | grep -v grep
    Пользователь 2944 11780? 03:31:10 /usr /sbin /cron
    Пользователь 2940 7284 pty1 19:58:41 /usr /bin /crontab

Пользователь @ Uva ~ $
ответил Antonio 11 Jpm1000000pmThu, 11 Jan 2018 21:51:17 +030018 2018, 21:51:17
3

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

Я создал файл mycronjob с расписанием cron, именем пользователя и amp; и скопировали его в каталог /etc/cron.d. Мои две ошибки:

  1. Файл mycronjob должен был принадлежать root для запуска
  2. Мне нужно было установить разрешения для файла на 644 - 664, и он не будет работать.

Проблема с разрешением появится в /var /log /syslog как нечто похожее на:

Apr 24 18:30:01 ip-11-22-33-44 cron [40980]: (* system *) INSECURE MODE (группа /другое записываемое) (/etc /crontab)
Apr 24 18:30:01 ip-11-22-33-44 cron [40980]: (* system *) INSECURE MODE (группа /другая запись) (/etc/cron.d/user)

Первая строка относится к файлу /etc /crontab, а позже - к файлу, который я помещал в /etc/cront.d.

ответил Antonio 11 Jpm1000000pmThu, 11 Jan 2018 21:51:17 +030018 2018, 21:51:17
2

Линия, написанная так, как не понимает crontab. Он должен быть правильно написан. Вот CrontabHowTo .

ответил Antonio 11 Jpm1000000pmThu, 11 Jan 2018 21:51:17 +030018 2018, 21:51:17
2

Демон Cron может работать, но фактически не работает. Попробуйте перезапустить cron:

sudo /etc/init.d/cron restart
ответил Antonio 11 Jpm1000000pmThu, 11 Jan 2018 21:51:17 +030018 2018, 21:51:17
2

Запись в cron через «crontab -e» с аргументом имени пользователя в строке. Я видел примеры пользователей (или системных администраторов), которые пишут свои сценарии оболочки и не понимают, почему они не автоматизируют. Аргумент «user» существует в файле /etc /crontab, но не в файлах, определенных пользователем. поэтому, например, ваш личный файл будет примерно таким:

# m h dom mon dow command

* * * /2 * * /some /shell /script

тогда как /etc /crontab будет:

# m h dom mon dow пользовательская команда

* * * /2 * * jdoe /some /shell /script

Итак, зачем вы делаете последнее? Ну, в зависимости от того, как вы хотите установить свои разрешения, это может стать очень запутанным. Я написал сценарии для автоматизации задач для пользователей, которые не понимают тонкости, или не хотят беспокоиться о тяжелой работе. Установив права на - x ------, я могу сделать исполняемый файл сценария без возможности чтения (и, возможно, случайно) его изменения. Тем не менее, я мог бы запустить эту команду с несколькими другими из одного файла (что упростит ее работу), но убедитесь, что для вывода файла назначен правильный владелец. Выполнение этого (по крайней мере, в Ubuntu 10.10) прерывает как невозможность прочитать файл, так и выполнить, плюс вышеупомянутую проблему с положением периодов в /etc /crontab (что, как ни странно, не вызывает ошибки при прохождении < code> crontab -e).

В качестве примера я видел примеры sudo crontab -e, используемые для запуска скрипта с правами root, с соответствующим chown username file_output в сценарии оболочки , Sloppy, но он работает. IMHO, более изящный вариант заключается в том, чтобы поместить его в /etc /crontab с объявленным пользователем и соответствующими разрешениями, поэтому file_output отправляется в нужное место и у владельца.

ответил Antonio 11 Jpm1000000pmThu, 11 Jan 2018 21:51:17 +030018 2018, 21:51:17
2

Построение того, что Аарон Пирт упомянул в режиме подробностей, иногда скрипты, не находящиеся в сложном режиме, будут инициализироваться, но не закончить, если поведение по умолчанию включенной команды заключается в выводе строки или более на экран после запуска proc. Например, я написал сценарий резервного копирования для нашей интрасети, который использовал curl, утилиту, которая загружает или загружает файлы на удаленные серверы, и весьма удобна, если вы можете обращаться к указанным удаленным файлам через HTTP. Использование «curl http://something.com/somefile.xls » вызывало сценарий, который я написал, чтобы висеть и никогда не заканчивается, потому что он выплевывает новую строку, за которой следует строка прогресса. Я должен был использовать молчащий флаг (-s), чтобы сообщить ему не выводить какую-либо информацию и писать в моем собственном коде для обработки, если файл не удалось загрузить.

ответил Antonio 11 Jpm1000000pmThu, 11 Jan 2018 21:51:17 +030018 2018, 21:51:17
2

Хотя вы можете определить переменные среды в своем подходе, вы не находитесь в сценарии оболочки. Поэтому такие конструкции, как следующие, не будут работать:

some_dir = /вар /журнал
MY_LOG_FILE = $ {SOME_LOG} /some_file.log

Bin_dir = /USR /местные /бен
MY_EXE = $ {bin_dir} /some_executable_file

0 10 * * * $ {MY_EXE} some_param>>> $ {MY_LOG_FILE}

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

Вместо этого вы должны прямо определить все переменные среды:

some_dir = /вар /журнал
MY_LOG_FILE = /вар /Журнал /some_file.log

Bin_dir = /USR /местные /бен
MY_EXE = /USR /местные /бен /some_executable_file

0 10 * * * $ {MY_EXE} some_param>>> $ {MY_LOG_FILE}
ответил Antonio 11 Jpm1000000pmThu, 11 Jan 2018 21:51:17 +030018 2018, 21:51:17
2

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

Примером может служить программа goaccess для анализа файлов журнала веб-сервера. Это НЕ работает в cron:

goaccess -a -f /var/log/nginx/access.log> output.html

и goaccess показывает страницу справки вместо создания отчета. В оболочке это можно воспроизвести с помощью

goaccess -a -f /var/log/nginx/access.log> output.html </DEV /нуль

Исправление для goaccess заключается в том, чтобы заставить его читать журнал из stdin вместо чтения из файла, поэтому решение состоит в том, чтобы изменить запись crontab на

cat /var/log/nginx/access.log | goaccess -a> output.html
ответил Antonio 11 Jpm1000000pmThu, 11 Jan 2018 21:51:17 +030018 2018, 21:51:17
2

На моих серверах RHEL7 будут выполняться задания root cron, но пользовательские задания не будут. Я обнаружил, что без домашнего каталога задания не будут выполняться (но вы увидите хорошие ошибки в /var /log /cron). Когда я создал домашний каталог, проблема была решена.

ответил Antonio 11 Jpm1000000pmThu, 11 Jan 2018 21:51:17 +030018 2018, 21:51:17
2

Если вы отредактировали свой файл crontab с помощью редактора окон (через samba или что-то еще), и он заменил новые строки \ n \ r или просто \ r, cron не будет работать.

Кроме того, если вы используете /etc/cron.d/*, и один из этих файлов имеет в нем \ r, cron будет перемещаться по файлам и останавливаться, когда он попадает в плохой файл. Не уверен, что это проблема?

Использование:

od -c /etc/cron.d/* | grep \ r
ответил Antonio 11 Jpm1000000pmThu, 11 Jan 2018 21:51:17 +030018 2018, 21:51:17
2

В 16.04, если у вас есть эта ошибка в syslog

(CRON) ошибка (не может fork)

попробовать:

systemctl status cron.service

В результате:

Задачи: num_task (ограничение: 512)

Если num_task близок к пределу использования:

systemctl set-property cron.service ЗадачиMax = new_max

Замените new_max на подходящее значение.

ответил Antonio 11 Jpm1000000pmThu, 11 Jan 2018 21:51:17 +030018 2018, 21:51:17

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132