Виконання crontab не має тих самих змінних середовища, що й користувач, що виконує


20

Я керував своїм завданням crontab 0 2 */1 * * /aScript >aLog.log 2>&1як "root" користувач, але, проте, я виявив, що env відрізняється від env користувача "root", і, отже, переживає мою скрипт по-різному.

Виправлення спроби було розміщення команд експорту у файли rc.d, але воно все ще не з’явилося! В кінцевому підсумку розміщую команди експорту в самому AScript .

Моє запитання, чи є кращий спосіб підійти до цієї проблеми? і чому env відсутній, навіть якщо він від того самого користувача «root»? (Я змінюю crontab, запускаючи 'crontab -e' від кореня)


8
Cron завжди працює з переважно порожнім середовищем. HOME, LOGNAME та SHELL встановлені; і дуже обмежений ПАТ. Якщо ви не хочете встановлювати всі змінні самостійно, можливо, ви зможете отримати sourceваш (bash) профіль.
cyberx86

2
@ cyberx86: Чому б не написати це як відповідь і отримати відповідь?
user9517 підтримує GoFundMonica

2
@Iain: представник завжди вітається, але іноді відчувається, що відповідь на один рядок насправді не заробляє реп. Я повністю погоджуюсь, що лаконічна відповідь має своє місце, але я (можливо, неправильно) використовую коментарі як "простий вихід", коли хотів надати деяку допомогу, але не написати повне, детальне пояснення (це було 1 ранку. ..). Однак я скористаюсь вашою порадою і розширюю цю проблему і додаю її як відповідь.
cyberx86

@ cyberx86: Краще мати правильний один вкладиш, ніж неправильний або нічого.
user9517 підтримує GoFundMonica

Відповіді:


31

Cron завжди працює з переважно порожнім середовищем. HOME, LOGNAME та SHELL встановлені; і дуже обмежений ПАТ. Тому доцільно використовувати цілі шляхи до виконуваних файлів та експортувати будь-які змінні, потрібні у вашому сценарії, під час використання cron.

Існує кілька підходів, якими ви можете скористатися для встановлення змінних оточуючого середовища в cron, але всі вони означають його встановлення у вашому сценарії.

Підхід 1:

Встановіть кожну змінну, необхідну вручну, у своєму сценарії.

Підхід 2:

Джерело вашого профілю:

. $HOME/.bash_profile(або . $HOME/.profile)

(Зазвичай ви виявите, що вищезазначений файл буде джерелом інших файлів (наприклад, ~ / .bashrc -> / etc / bashrc -> /etc/profile.d/*) - якщо ні, ви також можете надсилати ці файли.)

Підхід 3:

Збережіть змінні середовища у файл (запустіть як потрібний користувач):

env > /path/to/my_env.sh

Потім імпортуйте через ваш cron script:

env - `cat /path/to/my_env.sh` /bin/sh

Підхід 4:

У деяких випадках ви можете встановити глобальні змінні cron у /etc/default/cron. Однак для цього є елемент ризику, оскільки вони будуть встановлені для всіх робочих місць у галузі.


Підхід 2 найкраще підходить для серверів, де у вас є чутливі речі, які не повинні потрапляти на диск у оточенні - паролі, клавіші api тощо. Для мене творили чудеса, тож дякую.
ар

Підхід 4 працював на мене в докерських умовах, коли докерний двигун встановлює env vars. Щоб це не спрацювало, мені довелося зберегти моє оточення у точці входу докера. Повне рішення тут: github.com/rayyanqcri/swarm-scheduler
hammady

Не могли б ви детальніше розглянути підхід 3? Коли я намагаюся імпортувати його, я отримуюbash: SHELL=/bin/bash: No such file
KuboMD

1

Cron створює свою власну оболонку із застосуванням, визначеним через яке вона буде працювати.

Отже, якщо ви хочете зберегти ту саму змінну свого користувача, то спробуйте запустити її зі своїм власним користувачем замість root або будь-якого іншого користувача.

Або

Найкращий спосіб - експортувати ці змінні у свій власний сценарій.


1

У RedHat CentOS ви можете встановити /etc/rc.d/init.d/functions за замовчуванням PATH для постійного встановлення. /etc/rc.d/crond викликає функції при запуску.


0

У мене був аналогічний випуск на моєму AWS. Зрозумів це так

which python3

дав мені /usr/bin/local/python3місцезнаходження

і потім

. $HOME/.profile; /usr/local/bin/python3 /home/ubuntu/your_script.py
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.