Как запустить команду cron с существующими переменными среды?

Как запустить команду cron с существующими переменными среды?

Если я в командной строке, я могу набрать echo $ORACLE_HOMEи получить путь. Это одна из моих переменных окружения, которая устанавливается в моем ~/.profile. Тем не менее, кажется, что ~/.profileне загружаются сценарии fron cron и поэтому мои сценарии завершаются ошибкой, потому что $ORACLE_HOMEпеременная не установлена.

В этом вопросе автор упоминает о создании ~/.cronfileпрофиля, который устанавливает переменные для cron, а затем делает обходной путь для загрузки всех своих команд cron в скрипты, которые он хранит в своем ~/Cronкаталоге. Подобный файл ~/.cronfileзвучит как хорошая идея, но остальная часть ответа кажется немного громоздкой, и я надеялся, что кто-нибудь подскажет мне более простой способ получить тот же результат.

Я предполагаю, что в начале моих сценариев я мог бы добавить что-то вроде этого, source ~/.profileно, похоже, это может быть излишним.

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

В crontab перед командой добавьте . $HOME/.profile. Например:

0 5 * * * . $HOME/.profile; /path/to/command/to/run

Cronничего не знает о вашей оболочке; он запускается системой, поэтому он имеет минимальную среду. Если ты хочешь чего-то, тебе нужно это внести в себя.

Другой вариант, который я считаю более простым, - это запустить скрипт с помощью cron и иметь среду в скрипте.

В файле crontab -e:

SHELL=/bin/bash

*/1 * * * * $HOME/cron_job.sh

В файле cron_job.sh:

#!/bin/bash
source $HOME/.bash_profile
some_other_cmd

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

Другой вариант, который я считаю более простым, - это запустить скрипт с помощью cron и указать bash для входа (следовательно, используя /etc/profile.d/...определения среды)

В crontab -eфайле:

*/1 * * * * bash -l -c './cron_job.sh'
*/1 * * * * bash -l -c 'php -f ./cron_job.php'

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

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

Этот синтаксис определенно помогает вам. Я не понимаю синтаксис, но он работает. Oracle использует этот синтаксис при развертывании Oracle Configuration Manager в crontab, поэтому я считаю, что это правильное решение.

0 5 * * * SOME_ENV_VAR=some_value some_command some_parameters

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

# m  h  dom  mon  dow  user  command
*/5  *   *    *    *   root  (sudo -i -u <the user> command-to-be-run-as-user) && command-to-be-run-as-root

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

PS: обратите внимание, что userстолбец доступен только в /etc/crontabи /etc/cron.d/*файлы.

Решение, которое сработало для меня, описано здесь .

Вы создаете скрипт-обертку, который вызывает . ~/.cronfile, а затем делает то, что вам нужно. Этот скрипт запускается cron.

В ~/.cronfileвы указываете среду для ваших заданий cron.

Да, вы можете использовать «общеизвестные обходные пути» (несколько из которых были перечислены). Это еще один способ сказать, что все знают, что это дерьмо, хотя некоторые люди будут называть это «функцией безопасности», потому что они потратили, по крайней мере, столько же срабатываний на этот сбой, чем вы, и хотели бы думать, что их потерянное время не было напрасно. Это cron-эквивалент QWERTY-клавиатуры.

Я подозреваю, что первоначальная причина, возможно, была в производительности, так что скрипты, запускаемые раз в минуту, не тратили бы время на чтение скриптов rc. Также изначально cron вообще не был настраиваемым, так что по умолчанию был единственным вариантом.

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

Культура Unix провалилась. По моему "скромному" мнению. :-)

Добавлять

BASH_ENV=/home/user/.profile

в хронтаб. См. Как гарантировать доступность $ BASH_ENV

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

ENVIRONMENT=prod
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
*/30 * * * * /opt/myscript1.sh
*/30 * * * * /opt/myscript2.sh
*/30 * * * * /opt/myscript3.sh

Установка PATHс путем команд помогла мне. Еще лучше, если вы можете использовать шаблон и позже подвергать детламентации,

ENVIRONMENT={{ENVIRONMENT}}
PATH={{PATH}}
*/30 * * * * /opt/myscript1.sh
*/30 * * * * /opt/myscript2.sh
*/30 * * * * /opt/myscript3.sh

Передача переменных каждому элементу выглядит грязно.

Я кладу . ~/.dbus/session-bus/*в верхней части моего желаемого сценария :)