Почему dhclient + systemd-разрешенный перезапуск часто?

Я выполняю сервер человечности в aws на ВЕРСИИ = "18.10 (Космическая Каракатица)"

У нас были неустойчивые проблемы разрешения DNS, и при изучении этого я видел, что каждые 20 минут или таким образом, я вижу следующее в системном журнале

Mar 19 00:17:03 localhost dhclient[815]: DHCPREQUEST of 172.31.26.85 on eth0 to 172.31.16.1 port 67 (xid=0x7d329bb3)
Mar 19 00:17:03 localhost dhclient[815]: DHCPACK of 172.31.26.85 from 172.31.16.1
Mar 19 00:17:03 localhost systemd[1]: Stopping Network Name Resolution...
Mar 19 00:17:03 localhost systemd[1]: Stopped Network Name Resolution.
Mar 19 00:17:03 localhost systemd[1]: Starting Network Name Resolution...
Mar 19 00:17:04 localhost dhclient[815]: bound to 172.31.26.85 -- renewal in 1747 seconds.

Кажется, что каждый раз dhclient проходит процесс возобновления, который это заставляет systemd-разрешенный перезапускать, который на мгновение заставляет разрешение DNS не работать. Таким образом, если некоторый процесс работал в то время, разрешение может перестать работать.

Я не действительно уверен, где начать на этом. Действительно ли нормально для dhclient заставить systemd-разрешенный перезапускать так часто? Что правильное решение к этой проблеме? Я должен вынудить dhclient возобновлять намного менее часто, который оказывает некоторое негативное влияние? Какие-либо другие предложения?

3
задан 20 March 2019 в 02:46

1 ответ

Я не уверен, что точно вызывает dhclient обновление (особенно, потому что время владения по умолчанию в /etc/dhcp/dhclient.conf #send dhcp-lease-time 3600; иначе 1 час), но DNS ошибки разрешения, кажется, последствие этого обновления, инициировавшего a systemd-resolved перезапуск.

Я подтвердил это в своем собственном случае путем выполнения

sudo grep -Pi '(renewal|started network name)' /var/log/syslog | tail

который показал это systemd перезапустил бы после того, как время обновления протекло. Кроме того, я заметил это ps -ef | grep [r]esolv показал что systemd-resolved процесс никогда не выполнял fro больше чем 30 минут, в то время как другие серверы имели этот процесс, выполненный в течение многих недель за один раз.

После большого поиска с помощью Google и обыска и беспорядка, я столкнулся с патчем здесь:

--- /etc/dhcp/dhclient-enter-hooks.d/resolved.orig  2018-12-20 22:16:45.914466953 +0000
+++ /etc/dhcp/dhclient-enter-hooks.d/resolved   2018-12-20 23:15:03.861114407 +0000
@@ -26,10 +26,13 @@
               if [ ! "$interface" ] ; then
                   return
               fi
               statedir="/run/systemd/resolved.conf.d"
               mkdir -p $statedir
+
+              oldstate="$(mktemp)"
+              md5sum $statedir/isc-dhcp-v4-$interface.conf $statedir/isc-dhcp-v6-$interface.conf > $oldstate 2>&1
               if [ -n "$new_domain_name_servers" ] ; then
                   cat <<EOF >$statedir/isc-dhcp-v4-$interface.conf
 [Resolve]
 DNS=$new_domain_name_servers
 EOF
@@ -48,11 +51,19 @@
                       cat <<EOF >>$statedir/isc-dhcp-v6-$interface.conf
 Domains=$new_dhcp6_domain_search
 EOF
                   fi
               fi
-              systemctl try-reload-or-restart systemd-resolved.service
+
+              newstate="$(mktemp)"
+              md5sum $statedir/isc-dhcp-v4-$interface.conf $statedir/isc-dhcp-v6-$interface.conf > $newstate 2>&1
+              if ! cmp --quiet $oldstate $newstate; then
+                  systemctl try-reload-or-restart systemd-resolved.service
+              fi
+
+              rm $oldstate
+         rm $newstate
           }
                 ;;

           EXPIRE|FAIL|RELEASE|STOP)
               if [ ! "$interface" ] ; then

который я затем установил на своем сервере (серверах) путем сохранения его в some-file и затем выполнение sudo patch <some-file

В придачу я перезагрузил свой сервер, не уверенный, если это требуется.

4
ответ дан 1 December 2019 в 15:48

Другие вопросы по тегам:

Похожие вопросы: