Вопрос или проблема
Я пытаюсь выяснить причину выхода из строя экземпляра, который, похоже, вызван запланированным сервисом systemd refresh-policy-routes, за которым следует вызов 404 Error к EC2RoleProvider. После ошибки вся сетевая связь на экземпляре пропала (включая ssh). Что делает refresh-policy-routes?
Starting [email protected] - Обновление маршрутной политики для ens5...
Запуск sysstat-collect.service - инструмент учета системной активности...
sysstat-collect.service: Деактивировано успешно.
Завершено sysstat-collect.service - инструмент учета системной активности.
SERVICE_START pid=1 uid=0 auid=<sess> ses=<sess> subj=system_u:system_r:init_t:s0
msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
SERVICE_STOP pid=1 uid=0 auid=<sess> ses=<sess> subj=system_u:system_r:init_t:s0
msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Запуск конфигурации для ens5
/lib/systemd/systemd-networkd-wait-online ens5
[get_meta] Запрос IMDS для mac
Получен токен IMDSv2 с http://169.254.169.254/latest
Используется существующий cfgfile /run/systemd/network/70-ens5.network
[get_meta] Запрос IMDS для network/interfaces/macs/<mac-addr>/local-ipv4s
Получен токен IMDSv2 с http://169.254.169.254/latest
[get_meta] Запрос IMDS для network/interfaces/macs/<mac-addr>/ipv4-prefix
Получен токен IMDSv2 с http://169.254.169.254/latest
[get_meta] Запрос IMDS для network/interfaces/macs/<mac-addr>/local-ipv4s
Получен токен IMDSv2 с http://169.254.169.254/latest
Вызван захват
Перезагрузка networkd не требуется
[email protected]: Деактивировано успешно.
Завершено [email protected] - Обновление маршрутной политики для ens5.
SERVICE_START pid=1 uid=0 auid=<sess> ses=<sess> subj=system_u:system_r:init_t:s0
msg='unit=refresh-policy-routes@ens5 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
SERVICE_STOP pid=1 uid=0 auid=<sess> ses=<sess> subj=system_u:system_r:init_t:s0
msg='unit=refresh-policy-routes@ens5 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
2024-02-11 08:30:46 WARN EC2RoleProvider Не удалось подключиться
к Systems Manager с учетными данными профиля экземпляра.
Err: полученные учетные данные не смогли сообщить в ssm. Ошибка: EC2RoleRequestError: роль экземпляра EC2 не найдена
вызвано: EC2MetadataError: не удалось сделать запрос EC2Metadata
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>404 - Не найдено</title>
</head>
<body>
<h1>404 - Не найдено</h1>
</body>
</html>
код состояния: 404, идентификатор запроса:
Похоже, что поведение в cleanup и stop скрипта setup-policy-routes.sh было устранено (или исправлено).
Надеюсь, это обновление поможет вам.
https://github.com/amazonlinux/amazon-ec2-net-utils/pull/107
(слишком длинное) послесловие
Что делает refresh-policy-routes?
refresh-policy-routes@<iface>.service
refresh-policy-routes@<iface>.service вызывает скрипт setup-policy-routes дважды (по крайней мере в aws-ec2-net-utils v2.4.1).
Сначала скрипт вызывается с аргументом start, затем с cleanup.
ExecStart=/usr/bin/setup-policy-routes %i start
ExecStartPost=/usr/bin/setup-policy-routes %i cleanup
С аргументом start выполняется systemd-networkd-wait-online.
С аргументом cleanup удаляется файл блокировки, если он остался.
Но я пока не понимаю поведение точно.
info "Запуск конфигурации для $iface"
debug /lib/systemd/systemd-networkd-wait-online -i "$iface"
/lib/systemd/systemd-networkd-wait-online -i "$iface"
info "ПРЕДУПРЕЖДЕНИЕ: Очистка утеченной блокировки ${lockdir}/${iface}"
rm -f "${lockdir}/${iface}"
Кстати, сам юнит сервиса не имеет секции [Install] в своем файле юнита.
Поэтому его необходимо активировать другим способом. Здесь используется юнит типа timer.
refresh-policy-routes@<iface>.timer
Когда интерфейс подключен (или происходит какое-то подобное событие), активируется экземпляр юнита сервиса policy-routes@<iface>.service, который принадлежит интерфейсу через udev.
policy-routes@<iface>.service также вызывает setup-policy-routes дважды, так же как и refresh-policy-routes@<iface>.service.
ExecStart=/usr/bin/setup-policy-routes %i start
ExecStartPost=/usr/bin/setup-policy-routes %i cleanup
В то же время udev также включает refresh-policy-routes@<iface>.timer.
Но таймер ждет 30 секунд, чтобы активировать refresh-policy-routes@<iface>.service в первый раз.
А затем таймер повторно активирует сервис каждые одну-две минуты (насколько я заметил в своей среде).
[Timer]
OnActiveSec=30
OnUnitInactiveSec=60
RandomizedDelaySec=5
резюме
setup-policy-routes.sh вызывается много раз различными триггерами.
Неясно, что происходит (и что должно быть) на каждом этапе.
Это может привести к конфликтам с другими службами или компонентами, зависимыми от сети.
Я думаю, что потребуются некоторые параметры After= или Before= или подобные им (в файлах юнитов systemd), чтобы разрешить такие ситуации.
Похоже, это настраиваемая служба AWS
https://github.com/amazonlinux/amazon-ec2-net-utils/blob/main/systemd/system/refresh-policy-routes%40.service
Могу я узнать, какое было решение или обходной путь?. У меня была работающая служба LDAP на AL2, но после миграции на AL2023 входящий трафик от других компонентов перестал доходить до LDAP.
Ответ или решение
Что такое systemd "refresh-policy-routes" в AWS Linux 2023?
Служба refresh-policy-routes является частью системы управления сетевыми настройками в Amazon Linux 2023 и служит для обновления маршрутов политики сетевого интерфейса. Основная цель этой службы — обеспечить актуальность маршрутов, используемых для сетевого взаимодействия в облачной инфраструктуре AWS.
Структура и функции refresh-policy-routes
-
Запуск и остановка:
Службаrefresh-policy-routes@<iface>.serviceвызывается дважды:- Первый запуск: выполняется с аргументом
start, что подразумевает запуск скриптаsetup-policy-routesи ожидание завершения конфигурации сети с помощью командыsystemd-networkd-wait-online. - Второй запуск: выполняется с аргументом
cleanup, что служит для удаления временных файлов, таких как lock-файлы, которые могут остаться после работы первой части.
ExecStart=/usr/bin/setup-policy-routes %i start ExecStartPost=/usr/bin/setup-policy-routes %i cleanup - Первый запуск: выполняется с аргументом
-
Контекст выполнения:
Служба активируется через таймерrefresh-policy-routes@<iface>.timer, который ожидает 30 секунд после запуска системы перед первым выполнением и повторяет выполнение с интервалом в 1-2 минуты. Это может вызвать проблемы, если другие службы сети полагаются на актуальные маршруты в момент выполненияrefresh-policy-routes. -
Метаданные экземпляра EC2:
Как видно из предоставленного вами журнала, после запускаrefresh-policy-routesпроисходит вызов к консоли метаданных EC2 для получения настроек сетевых интерфейсов. Ошибка404при вызовеEC2RoleProviderуказывает на проблемы с получением временных учетных данных для доступа к SSM (AWS Systems Manager). Это также может свидетельствовать о потере сетевой связи из-за некорректной конфигурации маршрутов.
Причины проблем и возможные решения
Наиболее вероятной причиной сбоя сетевого соединения после выполнения службы refresh-policy-routes может быть конфликт с другими сетевыми службами, а также некорректная работа с временными файлами и задержками в обновлении маршрутов. Чтобы предотвратить подобные ситуации, стоит рассмотреть следующие подходы:
-
Улучшение порядка запуска:
Добавление директивAfter=иBefore=в файлы единиц (unit files) услуг может помочь синхронизировать выполнение служб и избежать конфликтов. -
Обновление конфигурации сети:
Убедитесь, что службаsetup-policy-routesадекватно обрабатывает изменения в конфигурации сети и что нет неполных или забытых маршрутов. Возможно, потребуется диагностировать поведение скрипта и изменить его так, чтобы он корректнее обрабатывал ситуации, когда сети нет или она временно недоступна. -
Мониторинг и алерты:
Установка мониторинга за лог-файлами службы позволит выявить проблемные моменты до возникновения серьезных сбоев. Использование сервисов мониторинга AWS, таких как CloudWatch, может помочь в этом.
Заключение
Служба refresh-policy-routes в AWS Linux 2023 играет ключевую роль в управлении маршрутизацией сетевого трафика для экземпляров EC2. Необходимость в тщательном управлении и настройке этой службы не должна игнорироваться, особенно в сценариях, где ваша система зависит от надежного сетевого взаимодействия. Улучшение порядка запуска и обработка сетевых конфигураций — важные шаги на пути к стабильной работе ваших сервисов на AWS.