Странная проблема со скриптом bash, запущенным cron
У меня есть скрипт bash, запускаемый cron каждый час в моем контейнере Docker:
#!/bin/bash
/usr/bin/generate_signing_key -k $AWS_SECRET_ACCESS_KEY -r $AWS_DEFAULT_REGION > /usr/local/nginx/s3_signature_key.txt
{ read -r val1
read -r val2
sed -i 's! aws_signing_key .*; *$! aws_signing_key '$val1';!; s! aws_key_scope .*; *$! aws_key_scope '$val2';!;' /etc/nginx/nginx.conf
} < /usr/local/nginx/s3_signature_key.txt
if [ -z "$(pgrep nginx)" ]
then
nginx -c /etc/nginx/nginx.conf
else
nginx -s reload
fi
Итак, он запускает скрипт Python generate_signing_key и сохраняет результат в s3_signature_key.txt файл. Затем sed принимает некоторые значения и обновляет nginx конфигурацию.
Скрипт работает при запуске вручную, и если я запускаю его в режиме cron:
cd / && run-parts --report /etc/cron.hourly
К сожалению, если cron запускает его сам, то он обнуляет выходной s3_signature_key.txt файл и стирает значения в конфигурации nginx.
Есть идеи, что здесь не так?
Это проблема не bash, а среды, в которой cron выполняет задания. Я проголосовал за переход на ServerFault, где это было бы дублированием этого: serverfault.com/questions/337631/…
AWS_SECRET_ACCESS_KEY и AWS_DEFAULT_REGION определяются опцией docker run -e и присутствуют в среде контейнера Docker.
Джон: Если я заменю $AWS_SECRET_ACCESS_KEY$AWS_DEFAULT_REGION статическими значениями, получится то же самое.
@SynRomana Не существует такого понятия, как «контейнерная среда докеров» — у каждого процесса есть своя собственная частная среда, и для cron заданий эта среда почти пуста. Я не знаком с generate_signing_key, но могу поспорить, что это зависит от чего-то, что не настроено в cron заданиях. Предложения: перенаправить его вывод ошибок куда-нибудь, чтобы вы могли видеть любые сообщения, которые он печатает, и добавить проверку ошибок в свой скрипт (например, если generate_signing_key завершается со статусом ошибки, скрипт не следует продолжать).
Где вы определяете
AWS_SECRET_ACCESS_KEYиAWS_DEFAULT_REGION?