Re: Network manager freezing on Ruby2.5 OpenSuSE 15.6
Masaru Nomiya <[email protected]> Sun, 28 Jun 2026 15:55:54 +0900
| Newsgroups | gmane.linux.suse.general |
|---|---|
| Message-ID | <[email protected]> |
Hello, In the Message; Subject : Re: Network manager freezing on Ruby2.5 OpenSuSE 15.6 Message-ID : <CAHeBFz1ShjLDTEkG73=CvsN4uWBxm_mHfcmJJMWGAH49nxG4iQ@mail.gmail.com> Date & Time: Sat, 27 Jun 2026 22:45:13 -0700 [CS] == Carl Spitzer <[email protected]> has written: CS> DCR>>>I'd like to know how Masaru new to check the size with ls CS> rather than to cat as normal to check the content. I suspect this CS> may not be the first issue with a large /etc/hosts. CS> Interesting a large ad blocking hosts causing the problem? CS> Hosts.txt aka Hosts is for ad blocking. So this is it! DucksDuckGo had actually shown me this old one, too; Just a note to close this thread. YaST Network Setting initialization running slow is a know and confirmed "behaviour", "feature" or "bug". It occurs because the /etc/hosts file is parsed and loaded as part of Network Setting initialization. The larger the /etc/hosts file, the longer Network Settings initialization takes and seems to be nlog(n) for Big O fans. Upshot is, if you are using hosts to block domains then you will notice the slow initialization in Network Settings, so just wait. A better solution to domain blocking is a DNS firewall which is what I was setting up when I stumbled upon this issue with Network Settings. I have implemented the unbound DNS resolver as a DNS firewall using RPZ to replace hosts blocking. Works like a charm. The only caveat is that RPZ is implemented in unbound v1.10 and the version in Leap 15.2 is v1.6. However, Tumbleweed (as of this writing) has a build of unbound v1.12 for Leap 15.2 which works fine. On, https://forums.opensuse.org/t/yast-nework-setting-hangs-during-initializing-network-configuration/142662/17 Best Regards. -- Masaru Nomiya mail-to: nomiya @ ab.auone-net.jp "Charlie is different. There are several steps to how it works, but to lay it out simply, imagine that all your data is stored in a vault owned and controlled by you. Charlie is effectively the gatekeeper to that vault and will interact on your behalf with any LLMs that request access to your data. Before it hands anything over, it will first ask for your permission. " -- "Charlie Is an AI Assistant Built to Serve You, Not Our AI Overlords" --