Baptiste, on 2019-09-17: > I have two critical systemd services running on my clients : > -> "puppet" that ensure propagation of my whole network configuration. > -> "samba winbind" that allow users pam authentication and Name Service > Switch. > These two services use DNS to find their services servers
Hi Baptiste, > Any Idea where I can start to search ? DNS resolvers are listed in /etc/resolv.conf: have a look and see if the content is consistent with your proper configuration. Network components tend to conflict for the control of /etc/resolv.conf (dhclient, NetworkManager, the admin and its trusty "vi" editor, etc). The program "resolvconf" can be installed to arbitrate this if necessary, although I've never used it for myself, yet. > Anything that I can try to identify the origin of the problem ? If those particular services are critical, and assuming your IP addresses attributions are static, at least for these core components of your network, then maybe you will want to consider using the plain IP address instead of relying on the DNS resolver's availability. At least, it would be worth trying this with a given machine, to see if services are starting correctly, or if you hit the next error message instead. [... rewinding ...] > But when the client recover from suspend these two services failed to > works until the next DNS query. > > -> Puppet give the following error : > puppet-agent[3312]: Failed to open TCP connection to puppet:8140 > (getaddrinfo: Name or service not known) Make sure your search domains are present in /etc/resolv.conf, otherwise your machine will certainly not be able to resolve the name "puppet". When you mention "suspend", is it after an actual hibernation ? There is a bug (more like poor wording in a startup message actually) in Debian 10.0 were the machine always seem to wake up from hibernation, which has been fixed in Debian 10.1. It could be worth upgrading to clarify this point, if it is not already the case. Are affected machines mobile ones ? If so, it could be caused by a complete change of network during the hibernation (while moving from home to the high school typically), and the resolver configuration was still the one from home somehow. À plus, :) -- Étienne Mollier <etienne.moll...@mailoo.org> Fingerprint: 5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d
signature.asc
Description: OpenPGP digital signature
