> On 1 Feb 2022, at 19:21, Michael Welle <[email protected]> wrote: > > Hello, > > Barry <[email protected]> writes: > >>>> On 31 Jan 2022, at 19:22, Dieter Maurer <[email protected]> wrote: >>> >>> Michael Welle wrote at 2022-1-30 09:18 +0100: >>>> ... >>> The machine this is running on regularly switches >>>> its network configuration without restarting the Python application. Now >>>> it turns out that the application is still using an old, outdated dns >>>> server after such a network configuration switch. >>> >>> It is unlikely that Python performs the host -> IP address translation >>> itself. Almost surely, the translation is delegated to functions >>> of the underlying C runtime library, e.g. "gethostbyname". >> >> And glibc does not have the ability to reload the /etc/resolv.conf I recall. >> If you rely on that you will need to change to using something like >> dnsmasq or systemd-resolved so that resolv.conf uses localhost. > hmmm, I don't know if that's all. For a test I just changed > /etc/resolv.conf manually while the application was sleeping. After > returning from sleep the application knew the change I had made in > resolv.conf and, interestingly, an exception (name resolution failure, > which is correct with the change I made) surfaces in the application. > That doesn't happen when the 'real' issue occurs. Attaching strace to > the Python process I can see that resolv.conf is stat'ed and open'ed. I > guess now I'm more confused than before ;). There must be an additional > condition that I'm missing.
That is good to know, last time I hit this was on centos 6 a little while ago. Barry > > Thanks for helping > hmw > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
