Bugzilla – Bug 1177835
Take ages to launch any application from Task Manager if connected to wifi network
Last modified: 2023-11-25 18:47:33 UTC
Fresh install of Tumbleweed on brand new laptop (literally finished installing a few minutes ago). I launched Firefox from the icon in Task Manager. It took more than a minute to launch. Of course in the meantime I tried several times and I ended up with 3 or 4 windows of it. Then I tried launching Konsole from launcher. Same exact thing. As if the whole system was hung and slow. Top didn't show any significant CPU usage by any process. Then I disconnected from wifi. Now again I tried again launching Firefox and Konsole, and they launched immediately as expected. Reconnected to wifi, tried again, disconnected again from wifi, tried again. Consistent results: when connected, everything takes ages to launch. This is the most stupid bug I've ever had to report (not just with OpenSUSE, in general). And it renders the system unusable.
I cannot believe this. I tried launching Firefox from a terminal and, after the long wait, it printed this error: _IceTransSocketUNIXConnect: Cannot connect to non-local host localhost which reminded me of this: https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5634 So I edited /etc/hostname which was empty and I gave my machine a name. Then I rebooted and now the issue is fixed. So the computer is completely unusable unless you set a hostname, and yet, the system installation doesn't prompt you to choose a host name.
(In reply to teo teo from comment #1) > So the computer is completely unusable unless you set a hostname, and yet, > the system installation doesn't prompt you to choose a host name. The installation sets a random hostname by default. If this is not not the case, this is a bug in the installation, reassigning.
> The installation sets a random hostname by default. If this is not not the > case, this is a bug in the installation, reassigning. Ok then that must be the bug. I installed Tumbleweed twice on two different computers and both times I got no hostname.
(In reply to teo teo from comment #3) > > The installation sets a random hostname by default. If this is not not the > > case, this is a bug in the installation, reassigning. > > Ok then that must be the bug. I installed Tumbleweed twice on two different > computers and both times I got no hostname. Please attach yast logs from installation ( output of save_y2logs script )
Created attachment 842795 [details] output from save_y2logs
(In reply to Fabian Vogt from comment #2) > (In reply to teo teo from comment #1) > > So the computer is completely unusable unless you set a hostname, and yet, > > the system installation doesn't prompt you to choose a host name. > > The installation sets a random hostname by default. If this is not not the > case, this is a bug in the installation, reassigning. We used to propose 'linux-XXXX' as the satic hostname at the end of the installation in case that the current hostname was 'install' that basically is the transient hostname that linuxrc sets at the beginning of the installation, but it was requested to stop doing that as part of some Hostname/DNS cleanup. https://github.com/yast/yast-network/blob/master/doc/hostname.md Current status: - We dropped the option for writing hostname as an alias for the loopback IP (127.0.0.1) - We dropped the domain input field, and although initially a FQDN was not allowed as the static hostname it is now. So, we will not force to use a short hostname while hostnamectl and the kernel permits the use of a FQDN. - In case that an interface is edited and configured with an static IP, we will still propose the use of the current hostname as an alias for that IP.
> We used to propose 'linux-XXXX' as the satic hostname at the end of the > installation in case that the current hostname was 'install' that basically > is the transient hostname that linuxrc sets at the beginning of the > installation, but it was requested to stop doing that as part of some > Hostname/DNS cleanup. Jiri, do you know anything about it ? Knut what you are suggestion to do here ?
(In reply to Stefan Schubert from comment #7) > > We used to propose 'linux-XXXX' as the satic hostname at the end of the > > installation in case that the current hostname was 'install' that basically > > is the transient hostname that linuxrc sets at the beginning of the > > installation, but it was requested to stop doing that as part of some > > Hostname/DNS cleanup. > Jiri, do you know anything about it ? > Knut what you are suggestion to do here ? I'm sorry, I cannot really suggest the best solution here, this calls for networking experts. It seems that - at least for the desktop use case - we need to write /etc/hostname (or find an alternative).
(In reply to teo teo from comment #1) > I cannot believe this. > > I tried launching Firefox from a terminal and, after the long wait, it > printed this error: > > _IceTransSocketUNIXConnect: Cannot connect to non-local host localhost > > which reminded me of this: > > https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5634 > > So I edited /etc/hostname which was empty and I gave my machine a name. > > Then I rebooted and now the issue is fixed. > > So the computer is completely unusable unless you set a hostname, and yet, > the system installation doesn't prompt you to choose a host name. I suppose that you are using NM and that when you configure the wifi your hostname change from 'localhost' to 'localhost.localdomain' is that correct? That would answer the problem about the printed error. And basically will happen with any change of the hostname. If it is the case, could you check /etc/hosts and add localhost.localdomain as the FQDN for 127.0.0.1 . That the same issue is experimented? BTW the change of hostname will continue happening unless you define a hostname or you tell NM to not set it. About set the hostname, well, it was requested to not propose a default anymore and keep what systemd-hostnamed sets that is "localhost", if that is not fine in all the scenarios, would be nice to know. Maybe it is something that we could highlight in the installation proposal to ensure the user is fine without one.
> I suppose that you are using NM I don't know what NM is. Network Manager? I don't know, I'm using whatever comes out of the box. I installed OpenSUSE Tumbleweed from a USB stick and chose KDE as the desktop manager. Whatever it installs is what I'm using. > and that when you configure the wifi your hostname change from > 'localhost' to 'localhost.localdomain' is that correct? I don't know. I wonder why it would do that but I have no idea. I'm not sure what you mean by "configure the wifi". During the install process, the installer failed to recognize the wifi card as per bug 1177834, and because the interface is stupid, I had no idea whether it had been able to set up the wifi or not (it hadn't). At the first boot, I connected to the wifi network for the first time as you would on any system that you use for the first time: I clicked on the network icon on the bottom-right of the screen, selected my SSID from the list, and entered my password. That's all the "configuration" I did for the wifi. > That would answer the problem about the printed error. > And basically will happen with any change of the hostname. I have never chosen to change the hostname. I wasn't prompted to pick a host name, I wasn't prompted whether I was fine with changing the host name. If something changed the hostname and that is causing issues, something is doing something wrong. Note that after I reported the bug, I edited /etch/hostname (which was empty) and added a host name that I like; then I rebooted, and everything works fine ever since. > If it is the case, could you check /etc/hosts and add > localhost.localdomain as the FQDN for 127.0.0.1 . That the same > issue is experimented? I'm not going to delete the host name in /etc/hostname just to test that, and I assume editing /etc/hosts would be useless now that I do have a /etc/hostname name and I'm not experiencing any issue to start with. I think you can test what you are asking me to test by doing a fresh install on any machine. Unless the issue is somehow caused by the failure to detect wifi during installation in issue 1177835, and something was left in a corrupt state during installation, in which case it would be trickier to reproduce because you'd need a machine where the wifi card doesn't get recognized properly during installation (but works fine afterwards), hence reproducing bug 1177835.
How is the severity of this not critical? The avarage user will find themselves with a freshly-installed system where opening any program takes minutes, and even if it is trivial to fix once you know the cause, for the avarage user it's very hard to figure out what the cause is.
(In reply to teo teo from comment #11) > How is the severity of this not critical? In every conceivable way. Please read the descriptions of those bug severities.
https://en.opensuse.org/openSUSE:Bug_definitions
Unless you are in a very special corporate network environment, you normally get an IP address and the hostname via DHCP. Normal WiFi routers are set up that way, and NetworkManager (which openSUSE uses by default) normally does that automatically. In the y2logs, I didn't see you changing any of the network defaults during installation; but it appears you hit the "Scan Network" button no less than 28 times. Did you have trouble detecting your WiFi? Is it possible that you have a special WiFi setup; one where the router's DHCP doesn't send a hostname along with the IP address?
I found something else in the y2logs: 2020-10-17 20:46:14 <3> install(3839) [Ruby] network/routines.rb(ControllerType):287 Unknown network controller type: $[ "bus":"PCI", "bus_hwcfg":"pci", "class_id":2, "device":"Killer Wi-Fi 6 AX1650i 160MHz Wireless Network Adapter (201NGW)", "device_id":79088, "drivers": [ $[ "active":true, "modprobe":true, "modules": [["iwlwifi",""]] ] ], "func_id":3, "modalias":"pci:v00008086d000034F0sv00008086sd00000234bc02sc80i00", "model":"Intel Killer Wi-Fi 6 AX1650i 160MHz Wireless Network Adapter (201NGW)", "old_unique_key":"fx0i.C0LA3_R13_8", "resource": $["irq": [ $[ "count":2, "enabled":true, "irq":16 ] ], "mem": [ $[ "active":true, "length":16384, "start":2166489088] ] ], "rev":"48", "slot_id":20, "sub_class_id":128, "sub_device_id":66100, "sub_vendor":"Intel Corporation", "sub_vendor_id":98438, "sysfs_bus_id":"0000:00:14.3", "sysfs_id":"/devices/pci0000:00/0000:00:14.3", "unique_key":"yX7n.C0LA3_R13_8", "vendor":"Intel Corporation", "vendor_id":98438 ] 2020-10-17 20:46:14 <3> install(3839) [Ruby] network/routines.rb(ControllerType):288 It's probably missing in hwinfo (NOT src/hd/hd.h:sc_net_if) ...but this might also be similar to this bug reported against Ubuntu a few months ago: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1874685 Killer(R) Wi-Fi 6 AX1650i 160MHz Wireless Network Adapter (201NGW), REV=0x354 [8086:a0f0] subsystem id [1a56:1651] wireless adapter not found due to firmware crash I might also be totally wrong here; but this looks like a hot trace to check.
(In reply to Stefan Hundhammer from comment #14) > Unless you are in a very special corporate network environment, you normally > get an IP address and the hostname via DHCP. Normal WiFi routers are set up > that way, and NetworkManager (which openSUSE uses by default) normally does > that automatically. > > In the y2logs, I didn't see you changing any of the network defaults during > installation; but it appears you hit the "Scan Network" button no less than > 28 times. Did you have trouble detecting your WiFi? I guess this part is already reported in a separated bug: https://bugzilla.suse.com/show_bug.cgi?id=1177834 > > Is it possible that you have a special WiFi setup; one where the router's > DHCP doesn't send a hostname along with the IP address? It is not send and as commented it is changed by NetworkManager to 'localhost.localdomain'. I was playing with the different roles, and apparently with GNOME and with the Generic desktop the issues is not faced but with KDE Plasma it is. Fabian, I was checking some similar bug, there are different ones in redhat / fedora. I supposed should be already solved, but not sure. https://bugzilla.redhat.com/show_bug.cgi?id=1370222 So basically the problem is produced by this steps: - YaST does not propose a hostname anymore during the installation. - The system starts and systemd sets the hostname to 'localhost'. - There is no network configured, so, the user configures the wireless connection and NetworkManager modifies the hostname to 'localhost.localdomain' (why not use the same as systemd-hostnamed does?) Note: There is not /etc/hosts entry in /etc/hosts with 'localhost.localdomain' Fabian, Stefan, it looks like sddm xauth problem because of the hostname change, isn't it?
My suspicion is that this is just the usual hostname change issue, but not only xauth is affected by that (solved by using FamilyWild), but also ICE (aka. X session management). NM probably changed the hostname from "localhost" to "localhost.localdomain" (which I consider a bug, reported elsewhere), but $SESSION_MANAGER contains the hostname from the login, before the connection was made. It looks like the previous (downstream only) method of $XAUTHLOCALHOSTNAME also works for Xtrans, so the simple fix here is to just set that again in SDDM. This is a downstream only solution though, and so I wonder what the upstreamable way to fix this would be... I'll create a test package for sddm.
(In reply to Fabian Vogt from comment #18) > It looks like the previous (downstream only) method of $XAUTHLOCALHOSTNAME > also works for Xtrans, so the simple fix here is to just set that again in > SDDM. This is a downstream only solution though, and so I wonder what the > upstreamable way to fix this would be... > > I'll create a test package for sddm. Done, please try: https://build.opensuse.org/package/show/home:Vogtinator:boo1177835/sddm If this works, I'll submit it as workaround, but will reassign to the xtrans maintainers with the hope of finding a proper solution.
> In the y2logs, I didn't see you changing any of the network > defaults during installation; but it appears you hit the "Scan Network" > button no less than 28 times. Did you have trouble detecting your WiFi? Yep, see https://bugzilla.opensuse.org/show_bug.cgi?id=1177834
(In reply to Fabian Vogt from comment #19) > (In reply to Fabian Vogt from comment #18) > > It looks like the previous (downstream only) method of $XAUTHLOCALHOSTNAME > > also works for Xtrans, so the simple fix here is to just set that again in > > SDDM. This is a downstream only solution though, and so I wonder what the > > upstreamable way to fix this would be... > > > > I'll create a test package for sddm. > > Done, please try: > https://build.opensuse.org/package/show/home:Vogtinator:boo1177835/sddm > > If this works, I'll submit it as workaround, but will reassign to the xtrans > maintainers with the hope of finding a proper solution. Hmm. p_xauth.diff is still applied in xtrans package. --- Xtranssock.c.orig 2009-10-16 23:25:57.000000000 +0200 +++ Xtranssock.c 2010-04-04 16:10:29.000000000 +0200 @@ -1790,12 +1790,15 @@ { char hostnamebuf[256]; + char* xauthlocalname = getenv("XAUTHLOCALHOSTNAME"); TRANS(GetHostname) (hostnamebuf, sizeof (hostnamebuf)); if (strcmp (hostnamebuf, host) == 0) { return (1); + } else if(xauthlocalname && strcmp (xauthlocalname, host) == 0) { + return (1); } else { #if defined(IPv6) && defined(AF_INET6) struct addrinfo *localhostaddr;
(In reply to Stefan Dirsch from comment #21) > (In reply to Fabian Vogt from comment #19) > > (In reply to Fabian Vogt from comment #18) > > > It looks like the previous (downstream only) method of $XAUTHLOCALHOSTNAME > > > also works for Xtrans, so the simple fix here is to just set that again in > > > SDDM. This is a downstream only solution though, and so I wonder what the > > > upstreamable way to fix this would be... > > > > > > I'll create a test package for sddm. > > > > Done, please try: > > https://build.opensuse.org/package/show/home:Vogtinator:boo1177835/sddm > > > > If this works, I'll submit it as workaround, but will reassign to the xtrans > > maintainers with the hope of finding a proper solution. > > Hmm. p_xauth.diff is still applied in xtrans package. Yes, but that's downstream only and so I can't actually submit my fixes upstream to sddm or KDE.
Now I understand. I'm not aware of an upstream solution of this issue. Maybe on other distributions this issue does not exist or they resolved it differently. Before trying to upstream our "XAUTHLOCALHOSTNAME" workaround this would need to be investigated.
(In reply to Fabian Vogt from comment #19) > (In reply to Fabian Vogt from comment #18) > > It looks like the previous (downstream only) method of $XAUTHLOCALHOSTNAME > > also works for Xtrans, so the simple fix here is to just set that again in > > SDDM. This is a downstream only solution though, and so I wonder what the > > upstreamable way to fix this would be... > > > > I'll create a test package for sddm. > > Done, please try: > https://build.opensuse.org/package/show/home:Vogtinator:boo1177835/sddm > > If this works, I'll submit it as workaround, but will reassign to the xtrans > maintainers with the hope of finding a proper solution. Ok, I will check.(In reply to Fabian Vogt from comment #19) > (In reply to Fabian Vogt from comment #18) > > It looks like the previous (downstream only) method of $XAUTHLOCALHOSTNAME > > also works for Xtrans, so the simple fix here is to just set that again in > > SDDM. This is a downstream only solution though, and so I wonder what the > > upstreamable way to fix this would be... > > > > I'll create a test package for sddm. > > Done, please try: > https://build.opensuse.org/package/show/home:Vogtinator:boo1177835/sddm > > If this works, I'll submit it as workaround, but will reassign to the xtrans > maintainers with the hope of finding a proper solution. I checked it and at least the error: _IceTransSocketUNIXConnect: Cannot connect to non-local host localhost is not shown anymore.
This appears to be stuck in NEEDINFO. Please check if the requested information has become available. Also, is this really an installer bug? It doesn't look like it to me. So please reassign it to the proper bugzilla component.
There looks like from YaST POV it is the expected behavior, so, the only thing that is still pending of an answer is the addition of localhost.localdomain to the default /etc/hosts file that is shipped with netcfg. Thus, assigning it to netcfg maintainer.
(In reply to Stefan Dirsch from comment #23) > Now I understand. I'm not aware of an upstream solution of this issue. Maybe > on other distributions this issue does not exist or they resolved it > differently. Before trying to upstream our "XAUTHLOCALHOSTNAME" workaround > this would need to be investigated. My current suspicion is that other distributions are also affected by this issue, but not in the default configuration. openSUSE tries extra hard to change the hostname and therefore cause this issue: By default the hostname is updated from DHCP (somewhat rare in networks) and wicked even does a reverse DNS lookup (much more common). The former is probably not the default in many distros and the latter is practically openSUSE specific.
localhost.localdomain has been added to /etc/hosts; I think this should fix this bug. Can anyone confirm?
Adding localhost.localdomain to /etc/hosts should have fixed this bug. If it happens again, please reopen this bug. Closing as fixed.