On Wed, 2022-04-27 at 08:05 -0400, Sam Varshavchik wrote: > The only reason systemd-resolved exists is because glibc caches > /etc/resolv.conf when a process performs its first DNS lookup. Having > the means to have an existing process become aware that its been > changed, and it should reread it, will completely eliminate the > reason for systemd-resolved's existence. That, I think, is the right > solution, and it was always the right solution. I remember that kind of thing when I first started using Linux in the early 2000s: It seemed to presume that all networks were a permanent thing. If a network went up and down again, be that ethernet or your dial-up internet, you had to manually restart NTP, and one or two other daemons. Things that rely on network (time servers, mail servers, etc), shouldn't just silently die and stay dead when a network changed. They should be able to notice a network status change and act accordingly. It's no good for a daemon to examine the network when it first starts up, and then never check again. And the converse isn't true. The network shouldn't be poking everything that might need to know about it. You'd be forever building an increasing number of wake-up routines. I don't know about the things that used to concern me, back then, I haven't checked lately. But we still have applications that are ignorant of network changes, like Firefox. If you try to load a site and networking fails it, that's it (whether your ISP connection was temporarily down, or a webserver on your LAN changed IPs). It's a case of manual jiggery pokery by you to get it have another go at it after it's cached a wrong or null DNS answer. -- uname -rsvp Linux 5.11.22-100.fc32.x86_64 #1 SMP Wed May 19 18:58:25 UTC 2021 x86_64 Boilerplate: All unexpected mail to my mailbox is automatically deleted. I will only get to see the messages that are posted to the mailing list. _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
