web-dev-qa-db-fra.com

Pourquoi dhclient + systemd-resolu redémarre-t-il fréquemment?

J'utilise un serveur ubuntu dans aws sur VERSION = "18.10 (Cosmic Cuttlefish)"

Nous avons eu des problèmes de résolution DNS intermittents, et en y regardant, j'ai vu que toutes les 20 minutes environ, je vois ce qui suit dans syslog

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.

Il semble que chaque fois que dhclient passe par un processus de renouvellement, il provoque le redémarrage de systemd-resolution, ce qui rend momentanément la résolution DNS inopérante. Donc, si un processus était en cours d'exécution à ce moment-là, la résolution peut échouer.

Je ne sais pas vraiment par où commencer. Est-il normal que dhclient provoque un redémarrage si fréquent de la résolution de systemd? Quelle est la bonne solution à ce problème? Dois-je forcer dhclient à renouveler beaucoup moins fréquemment, cela a-t-il un impact négatif? D'autres suggestions?

networkingdnsdisplay-resolutiondhcpsystemd-resolved
3
user3005200

Je ne sais pas exactement ce qui cause le renouvellement de dhclient (surtout parce que la durée de bail par défaut dans /etc/dhcp/dhclient.conf est #send dhcp-lease-time 3600; alias 1 heure), mais les erreurs de résolution DNS semblent être une conséquence de ce renouvellement déclenchant un systemd-resolved redémarrer.

J'ai confirmé cela dans mon propre cas en exécutant

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

ce qui a montré que systemd redémarrerait une fois le délai de renouvellement écoulé. De plus, j'ai remarqué que ps -ef | grep [r]esolv a montré que le systemd-resolved le processus n'a jamais fonctionné plus de 30 minutes, tandis que d'autres serveurs ont exécuté ce processus pendant des semaines.

Après beaucoup de recherches sur Google, de récurage et de confusion, je suis tombé sur un patch ici :

--- /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

que j'ai ensuite installé sur mes serveurs en l'enregistrant dans some-file puis en exécutant Sudo patch <some-file

Pour faire bonne mesure, j'ai redémarré mon serveur, je ne sais pas si cela est nécessaire.

4
dwanderson