Проблема со сценарием оболочки CentOS Linux: команды, похоже, выполняются не так, как ожидалось

#shell #cron

#оболочка #cron

Вопрос:

У меня есть полуприватный веб-сервер (например, его могут использовать только пользователи с определенным диапазоном IP-адресов, все остальные, кроме office, защищены брандмауэром), и мы изменили его, чтобы использовать сертификаты от Let’s Encrypt. Механизм аутентификации для этого отличается от предыдущих платных продуктов SSL, и, очевидно, что центр Let’s Encrypt должен иметь доступ к серверу во время запроса, а учитывая короткий срок действия файловых сертификатов, это обычно выполняется по расписанию.

По этой причине я написал новый сценарий оболочки Linux, чтобы убедиться, что пересмотренный процесс будет работать. В частности, при первом написании сценарий оболочки выполнял 4 действия, которые, как я думал, были в абсолютной / жесткой последовательности:

  1. Остановите брандмауэр
  2. Запустите клиент Let’s Encrypt
  3. Перезапустите httpd
  4. Запустите брандмауэр снова.

Раньше все работало нормально, но ранее в этом году процесс перестал работать должным образом, в частности, попытки клиента Let’s Encrypt обновить сертификаты завершились неудачей, и я получил по электронной почте предупреждения от Let’s Encrypt о том, что срок действия сертификата истекает, я думаю, это было потому, что файловый центр не смог связаться с сервером (брандмауэр по какой-то причине не остановился). Этот скрипт упоминается в задании Cron, и он настроен на вывод своих результатов в файл журнала. Я смог разбить задание и выполнить его вручную, в какой-то момент это даже сработало, запустив скрипт самостоятельно, т. Е. когда я запустил его, в отличие от того, чтобы позволить cron запустить его. Но это не работает автоматически.

Мы используем CentOS 7.

Предполагая, что это может быть связано со временем суток, я изменил расписание для скрипта в Cron с раннего утра до поздней ночи, сегодня я обнаружил, что он запустился и обновил сертификат нормально, но так и не перезапустил httpd. Я также посмотрел на службу брандмауэра, и, похоже, она также не перезапускалась в течение некоторого времени.

Возможно, я делаю что-то глупое, но это похоже на проблему с последовательностью. У меня нет никаких «хэшбангов» в моем скрипте. Строка кода в Cron, которая запускает процесс, является:

 30 3 * * * /backup/checklecert.sh > /backup/log/checklecert.txt
  
 service firehol stop
certbot renew --renew-by-default
service httpd restart
service firehol start
  

Команды должны выполняться последовательно (т. Е. Выполняется каждая команда, и система ожидает ее завершения, прежде чем перейти к следующей), и это должно заставить все работать так, как я ожидаю.

На самом деле происходит то, что, похоже, выполняются только некоторые команды в моем скрипте или что они выполняются не в строгой последовательности.

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

 10 20 * * 1 /backup/checklecert.sh > /backup/log/checklecert.txt
  

Файл кода для «checklecert.sh «является:

 service firehol stop
certbot renew --renew-by-default
service httpd restart
service firehol start
  

Комментарии:

1. У скрипта нет сбоя? Разве это не смущает cron?

2. Нет, в нем нет сбоя. Будет ли это иметь значение?

Ответ №1:

https://github.com/certbot/certbot/issues/6379 опция —renew-by-default не рекомендуется. Я бы порекомендовал shebang, хотя демон cron должен установить переменную оболочки по умолчанию.

Комментарии:

1. Спасибо tDarkCrystal. Я попробую добавить ошибку и посмотреть, работает ли это, до сегодняшнего дня даже не знал, что это такое : } Когда это работало должным образом, я просто использовал used renew, но добавил принудительное обновление, чтобы я мог протестировать изменения. Я полностью намерен избавиться от этого, когда у меня все снова заработает.