Кронтаб говорит, что команда не найдена [dубликат]

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

неправильные разрешения для обозначения нот кнтабата.

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

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

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

456
задан 8 May 2017 в 21:15

108 ответов

Разная среда

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

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

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

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

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

#!/bin/bash PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin # rest of script follows

Некоторые предпочитают просто использовать абсолютные пути ко всем командам. Я рекомендую против этого. Подумайте, что произойдет, если вы хотите запустить скрипт в другой системе, и в этой системе команда находится в /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:/bin 15 1 * * * backupscript --incremental /home /root
422
ответ дан 18 July 2018 в 10:39

Разная среда

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

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

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

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

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

#!/bin/bash PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin # rest of script follows

Некоторые предпочитают просто использовать абсолютные пути ко всем командам. Я рекомендую против этого. Подумайте, что произойдет, если вы хотите запустить скрипт в другой системе, и в этой системе команда находится в /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:/bin 15 1 * * * backupscript --incremental /home /root
422
ответ дан 18 July 2018 в 10:39

Разная среда

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

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

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

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

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

#!/bin/bash PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin # rest of script follows

Некоторые предпочитают просто использовать абсолютные пути ко всем командам. Я рекомендую против этого. Подумайте, что произойдет, если вы хотите запустить скрипт в другой системе, и в этой системе команда находится в /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:/bin 15 1 * * * backupscript --incremental /home /root
422
ответ дан 24 July 2018 в 19:37

Разная среда

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

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

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

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

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

#!/bin/bash PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin # rest of script follows

Некоторые предпочитают просто использовать абсолютные пути ко всем командам. Я рекомендую против этого. Подумайте, что произойдет, если вы хотите запустить скрипт в другой системе, и в этой системе команда находится в /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:/bin 15 1 * * * backupscript --incremental /home /root
422
ответ дан 24 July 2018 в 19:37

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

SOME_DIR=/var/log MY_LOG_FILE=${SOME_LOG}/some_file.log BIN_DIR=/usr/local/bin MY_EXE=${BIN_DIR}/some_executable_file 0 10 * * * ${MY_EXE} some_param >> ${MY_LOG_FILE}

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

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

SOME_DIR=/var/log MY_LOG_FILE=/var/log/some_file.log BIN_DIR=/usr/local/bin MY_EXE=/usr/local/bin/some_executable_file 0 10 * * * ${MY_EXE} some_param >> ${MY_LOG_FILE}
2
ответ дан 18 July 2018 в 10:39

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

sudo /etc/init.d/cron restart
2
ответ дан 18 July 2018 в 10:39

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

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

20
ответ дан 18 July 2018 в 10:39

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

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

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

16
ответ дан 18 July 2018 в 10:39

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

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

#!/bin/bash some commands tar cvfz /my/archive/file.tar.gz /my/shared/directory come more commands

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

#!/bin/bash some commands tar cfz /my/archive/file.tar.gz /my/shared/directory some more commands
9
ответ дан 18 July 2018 в 10:39

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

# m h dom mon dow command * * */2 * * /some/shell/script

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

# m h dom mon dow user command * * */2 * * jdoe /some/shell/script

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

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

2
ответ дан 18 July 2018 в 10:39

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

(CRON) error (can't fork)

try:

systemctl status cron.service

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

Tasks: num_task (limit: 512)

If num_task близок к использованию предела:

systemctl set-property cron.service TasksMax=new_max

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

2
ответ дан 18 July 2018 в 10:39

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

* * * * * /path/to/script >> /tmp/output

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

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

, чтобы узнать, помогает ли эта проблема.

4
ответ дан 18 July 2018 в 10:39

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

(8):

If neither the --lsbsysinit option nor the --regex option is given then the names must consist entirely of upper and lower case letters, dig‐ its, underscores, and hyphens. If the --lsbsysinit option is given, then the names must not end in .dpkg-old or .dpkg-dist or .dpkg-new or .dpkg-tmp, and must belong to one or more of the following namespaces: the LANANA-assigned namespace (^[a-z0-9]+$); the LSB hierarchical and reserved namespaces (^_?([a-z0-9_.]+-)+[a-z0-9]+$); and the Debian cron script namespace (^[a-zA-Z0-9_-]+$).

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

80
ответ дан 18 July 2018 в 10:39

Небезопасное разрешение таблицы 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]: (user) INSECURE MODE (mode 0600 expected) (crontabs/user)

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

# correct permission sudo chmod 600 /var/spool/cron/crontabs/user # signal crond to reload the file sudo touch /var/spool/cron/crontabs
13
ответ дан 18 July 2018 в 10:39

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

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

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

od -c /etc/cron.d/* | grep \r
2
ответ дан 18 July 2018 в 10:39

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

2
ответ дан 18 July 2018 в 10:39

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

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

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

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

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

10
ответ дан 18 July 2018 в 10:39

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

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

Although cron requires that each entry in a crontab end in a newline character, neither the crontab command nor the cron daemon will detect this error. Instead, the crontab will appear to load normally. However, the command will never run. The best choice is to ensure that your crontab has a blank line at the end. 4th Berkeley Distribution 29 December 1993 CRONTAB(1)
281
ответ дан 18 July 2018 в 10:39

Демон Cron не работает.

Тип:

pgrep cron

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

EDIT: вместо вызова сценариев инициализации через /etc/init.d используйте служебную утилиту, например

sudo service cron start
119
ответ дан 18 July 2018 в 10:39

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

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

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

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

Apr 24 18:30:01 ip-11-22-33-44 cron[40980]: (*system*) INSECURE MODE (group/other writable) (/etc/crontab) Apr 24 18:30:01 ip-11-22-33-44 cron[40980]: (*system*) INSECURE MODE (group/other writable) (/etc/cron.d/user)

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

3
ответ дан 18 July 2018 в 10:39

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

В некоторых системах (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

или

service rsyslog restart

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

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

cat /var/log/syslog | grep cron

.

23
ответ дан 18 July 2018 в 10:39

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

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

# m h dom mon dow command 0 0 * * * /bin/grep ERROR /home/adam/run.log &> /tmp/errors

Вместо:

# m h dom mon dow command 0 0 * * * grep ERROR /home/adam/run.log &> /tmp/errors

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

27
ответ дан 18 July 2018 в 10:39

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

2
ответ дан 18 July 2018 в 10:39

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

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

Попробуйте запустить команду в sh, чтобы увидеть, работает ли она. Завершите команду в подошве bash, чтобы убедиться, что она запущена в bash: bash -c "mybashcommand" Скажите cron, чтобы запустить все команды в bash, установив оболочку в верхней части вашего crontab : SHELL=/bin/bash Если команда является скриптом, убедитесь, что скрипт содержит shebang: #!/bin/bash
55
ответ дан 18 July 2018 в 10:39

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

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

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

Oct 24 07:51:00 mybox cron[29024]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host Oct 24 07:52:00 mybox cron[29063]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host Oct 24 07:53:00 mybox cron[29098]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host Oct 24 07:54:00 mybox cron[29527]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host

Все, что вам нужно do запускается:

# passwd -u <USERNAME>

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

6
ответ дан 18 July 2018 в 10:39

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

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

User@Uva ~ $ ps -ef | grep cron | grep -v grep User 2940 7284 pty1 19:58:41 /usr/bin/crontab SYSTEM 11292 636 ? 22:14:15 /usr/sbin/cro

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

Вот последовательность команд, которая заставила меня двигаться: [ ! d3] User@Uva ~ $ cron-config The cron daemon can run as a service or as a job. The latter is not recommended. Cron is already installed as a service under account LocalSystem. Do you want to remove or reinstall it? (yes/no) yes OK. The cron service was removed. Do you want to install the cron daemon as a service? (yes/no) yes Enter the value of CYGWIN for the daemon: [ ] ntsec You must decide under what account the cron daemon will run. If you are the only user on this machine, the daemon can run as yourself. This gives access to all network drives but only allows you as user. To run multiple users, cron must change user context without knowing the passwords. There are three methods to do that, as explained in http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-nopasswd1 If all the cron users have executed "passwd -R" (see man passwd), which provides access to network drives, or if you are using the cyglsa package, then cron should run under the local system account. Otherwise you need to have or to create a privileged account. This script will help you do so. Do you want the cron daemon to run as yourself? (yes/no) no Were the passwords of all cron users saved with "passwd -R", or are you using the cyglsa package ? (yes/no) no Finding or creating a privileged user. The following accounts were found: 'cyg_server' . This script plans to use account cyg_server. Do you want to use another privileged account name? (yes/no) yes Enter the other name: User Reenter: User Account User already exists. Checking its privileges. INFO: User is a valid privileged account. INFO: The cygwin user name for account User is User. Please enter the password for user 'User': Reenter: Running cron_diagnose ... ... no problem found. Do you want to start the cron daemon as a service now? (yes/no) yes OK. The cron daemon is now running. In case of problem, examine the log file for cron, /var/log/cron.log, and the Windows event log (using /usr/bin/cronevents) for information about the problem cron is having. Examine also any cron.log file in the HOME directory (or the file specified in MAILTO) and cron related files in /tmp. If you cannot fix the problem, then report it to cygwin@cygwin.com. Please run the script /usr/bin/cronbug and ATTACH its output (the file cronbug.txt) to your e-mail. WARNING: PATH may be set differently under cron than in interactive shells. Names such as "find" and "date" may refer to Windows programs. User@Uva ~ $ ps -ef | grep cron | grep -v grep User 2944 11780 ? 03:31:10 /usr/sbin/cron User 2940 7284 pty1 19:58:41 /usr/bin/crontab User@Uva ~ $

3
ответ дан 18 July 2018 в 10:39

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

sudo service cron restart
34
ответ дан 18 July 2018 в 10:39

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

2
ответ дан 18 July 2018 в 10:39

Когда задача выполняется в 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/null

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

cat /var/log/nginx/access.log | goaccess -a > output.html
2
ответ дан 18 July 2018 в 10:39

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

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

14
ответ дан 18 July 2018 в 10:39

Другие вопросы по тегам:

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