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" --