> On 1 Feb 2022, at 19:21, Michael Welle <mwe012...@gmx.net> wrote: > > Hello, > > Barry <ba...@barrys-emacs.org> writes: > >>>> On 31 Jan 2022, at 19:22, Dieter Maurer <die...@handshake.de> 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
