My initial conclusion may not have been correct. I now think that the fix in iproute2 4.15.0-2ubuntu1.3 made the problem more apparent.
The Network Name Resolution service is not actually failing. It is being stopped and restarted (based on the logs). So the real problem seems to be a very aggressive approach to restarting the Network Name Resolution service. In our case, the DHCPClient request is not getting a response, yet the Network Name Resolution service is still being restarted. Mar 13 03:43:32 em-vf-ns1 dhclient[3443]: DHCPDISCOVER on nsblk01 to 255.255.255.255 port 67 interval 5 (xid=0xe499a07d) Mar 13 03:43:37 em-vf-ns1 dhclient[3443]: No DHCPOFFERS received. Mar 13 03:43:37 em-vf-ns1 dhclient[3443]: No working leases in persistent database - sleeping. Mar 13 03:43:37 em-vf-ns1 systemd[1]: Stopping Network Name Resolution... Mar 13 03:43:37 em-vf-ns1 systemd[1]: Stopped Network Name Resolution. Mar 13 03:43:37 em-vf-ns1 systemd[1]: Starting Network Name Resolution... Mar 13 03:43:37 em-vf-ns1 systemd[1]: Started Network Name Resolution. Mar 13 03:43:37 em-vf-ns1 systemd[1]: Starting resolvconf-pull-resolved.service... Mar 13 03:43:37 em-vf-ns1 systemd[1]: Started resolvconf-pull-resolved.service. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to iproute2 in Ubuntu. Matching subscriptions: iproute2 https://bugs.launchpad.net/bugs/1919003 Title: Network Name Resolution fails with iproute2 4.15.0-2ubuntu1.3 Status in iproute2 package in Ubuntu: New Bug description: The following is repeated periodically in the syslog: Feb 28 20:25:02 em-cel1 systemd[1]: Started Network Name Resolution. Feb 28 20:25:02 em-cel1 systemd[1]: Starting resolvconf-pull-resolved.service... Feb 28 20:25:02 em-cel1 systemd[1]: Started resolvconf-pull-resolved.service. Feb 28 20:25:19 em-cel1 systemd[1]: Stopping Network Name Resolution... Feb 28 20:25:19 em-cel1 systemd[1]: Stopped Network Name Resolution. Feb 28 20:25:19 em-cel1 systemd[1]: Starting Network Name Resolution... There is no log anywhere to indicate why the service failed. The service stopped failing when we downgraded iproute2 from 4.15.0-2ubuntu1.3 to 4.15.0-2ubuntu1.1. The DHCPClient seems to be involved in the chain of events. At the same frequency as the service failures, we do an ifup on a non- auto dhcp interface. The ifup results in a DHCP request, which in this case does not get a response (the link to the DHCP server is down. When we stop the process that does the periodic ifup, the service remains up (with iproute2 4.15.0-2ubuntu1.3). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/1919003/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
