wslg
wslg copied to clipboard
microsoft
(1.0.55 pre-release) Changing network causes all WSL windows to disappear
Windows build number:
10.0.19045.3086, I was able to reproduce it on 10.0.22621.1992 as well
Your Distribution version:
22.04
Your WSL versions:
WSL version: 1.3.14.0 Kernel version: 5.15.90.3-1 WSLg version: 1.0.55 MSRDC version: 1.2.4419 Direct3D version: 1.608.2-61064218 DXCore version: 10.0.25880.1000-230602-1350.main Windows version: 10.0.19045.3086
Steps to reproduce:
- Install the latest WSL pre-release (1.3.14 bundling WSLg 1.0.55 at the time of writing)
- Start any GUI application (in my repro, I'm running
xclock -update 1command from Windows Terminal but this seems to be reproducible with any app - I noticed it with Sublime Text 4 and kitty too; no matter if the app is set to use X11 or Wayland) - Disconnect from Wi-Fi or, if you're using Ethernet card, disable the network adapter that connects you to the Internet in Control Panel.
- See that all Linux app windows disappear once the connection is stopped.
WSL logs:
WslLogs-2023-07-31_18-43-52.zip stderr.log wlog.log pulseaudio.log weston.log
WSL dumps:
No files are available in the /mnt/wslg/dumps directory.
Expected behavior:
I expect the windows of Linux apps to still be visible after I disconnect from the network.
Actual behavior:
All windows of the Linux apps disappear.
It's possible that this is a WSL issue rather than WSLg's - while on my personal PC I was only able to see any difference with GUI apps, on my company laptop I noticed that there's also a different networking change (that does not apply to my personal setup where I don't use any VPNs) done when WSL detects proxy change (i.e. when I connect to company VPN) - it adds http_proxy env var and it shows notification that WSL should be restarted for network changes to apply (both of which I would actually really love to disable since I already have a working setup using redsocks which doesn't require me to set any env vars or to restart WSL).
Since my main issue is with the GUI apps disappearing on me and since everything else does work fine on my personal PC, I figured it makes more sense to create the issue here (and perhaps file another one for the proxy stuff on the main repo later).
I see the same issue (i've reported this in the release discussion, see https://github.com/microsoft/WSL/discussions/10302#discussioncomment-6504163, but i guess opening an issue is the better approach)
Welp, GitHub searched has failed me, I did look for a release discussion at some point before pinpointing what the issue is. But yeah I guess making a tracking issue for this isn't a bad idea anyway 😄
apparently I searched for "1.3" and for "1.3.10" and wrongly assumed that pre-releases probably don't have release discussions associated with them
same behavior of closing windows still happens with releases 1.3.15 and 1.3.17 ..
just noticed that after sleep my wifi interfaces were gone (blank list, smth with device probably), emacs window was available. Once it finally scanned wifi networks and reconnected to my home wifi, emacs windows disappeared. I have simillar errors in wlog.log as issue reporter:
[13:40:43:339] [11:11] [ERROR][com.freerdp.core.transport] - BIO_read returned a system error 11: Resource temporarily unavailable
[13:40:43:343] [11:11] [ERROR][com.freerdp.core] - transport_read_layer:freerdp_set_last_error_ex ERRCONNECT_CONNECT_TRANSPORT_FAILED [0x0002000D]
[13:40:43:367] [11:11] [ERROR][com.freerdp.core.transport] - BIO_should_retry returned a system error 32: Broken pipe
[13:40:43:367] [11:11] [ERROR][com.freerdp.core.transport] - BIO_should_retry returned a system error 32: Broken pipe
[13:40:43:367] [11:11] [ERROR][com.freerdp.core.transport] - BIO_should_retry returned a system error 32: Broken pipe
[13:40:43:367] [11:11] [ERROR][com.freerdp.core.transport] - BIO_should_retry returned a system error 32: Broken pipe
[13:40:43:367] [11:11] [ERROR][com.freerdp.core.transport] - BIO_should_retry returned a system error 32: Broken pipe
[13:40:44:469] [11:11] [ERROR][com.freerdp.core.transport] - BIO_should_retry returned a system error 32: Broken pipe
[13:40:44:469] [11:11] [ERROR][com.freerdp.core.transport] - BIO_should_retry returned a system error 32: Broken pipe
any way to do rollback without losing my distro?
Restarting WSL using WSL --shutdown and then opening a new window doesn't fix it? I know that fixes issues around external drives not being available for use if they were ejected at any point during the life of WSL , so it's worth a shot
Restarting WSL using WSL --shutdown and then opening a new window doesn't fix it?
Sure, so does killing the individual GUI processes inside the running WSL instance and just opening them again but it shouldn't be happening in the first place, especially considering that this used not to be a problem.
Restarting WSL using WSL --shutdown and then opening a new window doesn't fix it? I know that fixes issues around external drives not being available for use if they were ejected at any point during the life of WSL , so it's worth a shot
it's more like if you start another window/gui application, all disappeared windows appear, but my emacs-client windows remains unresponsive though. Killing and restarting it works, but it's annoying, I'm losing my open buffers etc literally after every sleep.
Restarting WSL using WSL --shutdown and then opening a new window doesn't fix it?
Sure, so does killing the individual GUI processes inside the running WSL instance and just opening them again but it shouldn't be happening in the first place, especially considering that this used not to be a problem.
agree. It's kind of basic scenario of use (does MS perform any testing though :D )
Restarting WSL using WSL --shutdown and then opening a new window doesn't fix it?
Sure, so does killing the individual GUI processes inside the running WSL instance and just opening them again but it shouldn't be happening in the first place, especially considering that this used not to be a problem.
I am aware and at no point did I say that it was a fix for the issue or anything more than a stopgap. The question was is there any way to fix it without losing the distro, which made it sound like they were just never coming back instead of only being temporarily unavailable.
The question was is there any way to fix it without losing the distro, which made it sound like they were just never coming back instead of only being temporarily unavailable.
Ah, you were referring to the question. My belief is that the question was actually asking whether there is a way to rollback to an older (non-prerelease) version of WSL and to answer that - yes, there is. I believe wsl --update --rollback should work, that's what I did when running into this issue to confirm that it's in fact a new problem.
The question was is there any way to fix it without losing the distro, which made it sound like they were just never coming back instead of only being temporarily unavailable.
Ah, you were referring to the question. My belief is that the question was actually asking whether there is a way to rollback to an older (non-prerelease) version of WSL and to answer that - yes, there is. I believe
wsl --update --rollbackshould work, that's what I did when running into this issue to confirm that it's in fact a new problem.
thanks! tried wsl --update --rollback before asking, there is no --rolback parameter on my instance for some reason:
it just prints help instead of rolling version back 🤔
Welp, it was the only relevant command I found in my history so I assumed it must have been how I did it. Clearly that's not the case then. Based on my recollection, the only other way I could have achieved it is by simply downgrading WSL with the latest stable msixbundle from WSL repository (https://github.com/microsoft/WSL/releases/tag/1.2.5). Once downloaded, you just have to open it, confirm that you want to downgrade in the MS Store prompt and wait for it to complete. I am not certain there are no risks associated with this but it did seem to work just fine in testing.
still happens to me with
WSL: 2.0.0.0
WSLg: 1.0.57
actually to me it looks like https://github.com/microsoft/wslg/issues/1108
still happens with 2.0.4. I thought the new wslinfo command might get some insights but alas it just tells me that i use nat which i knew beforehand :-)
Weird thing that I tested it with emacs client window and xfce4-terminal, emacs disappears after network change and reappears after opening another frame but unresponsive. Xfce4-terminal doesn't disappear and responsive
I primarily use (ubuntu 22.04's standard) emacs where i get the disappearing-window problem but quick experimentation shows also same behavior's with new pgtk emacs 29 or newer, xterm, gnome-text-editor and, contrary to Dmitry's experience, also with xfce4-terminal. Also, starting a new xapp usually makes them all re-appear ~and being responsive~. Contrary to what i thought, though, only standard emacs is responsive but not the other ones.
The caveat "usually" is that sometimes when the network dis/reconnects is due to a hibernation, then the xapps die (which seems due to that wslg/x-server dies and while automatically restarted obviously doesn't "inherit" the apps running at crash time ...)
Started to happen to me as well today.
WSL version: 2.0.9.0
Kernel version: 5.15.133.1-1
WSLg version: 1.0.59
MSRDC version: 1.2.4677
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22621.2428
WOW! This is truly annoying, no way to rollback and every change in network I must reopen all my windows. Is there anyone from Microsoft on this thread?
OK, I give up, I was perfectly happy with WSL, except from two events that completely broke it:
- suspend/resume regression due to Microsoft fix[1], which was resolved for Windows 11 22H2 and not for earlier versions
- this one which is a regression, but I cannot find the root cause.
@Jackenmen please modify title to allow people find this issue, something like: "X applications stop responding when Windows network is modified"
I truly want to avoid installing xserver.
[1] https://github.com/microsoft/WSL/issues/6982
please modify title to allow people find this issue, something like: "X applications stop responding when Windows network is modified"
That sounds more like #1108. The underlying cause may be the same but @hideyukn88 (maintainer of this project) wanted to keep those separate so I imagine changing the title in this way here would work against that. More so, this is NOT limited to X applications and affects Wayland as well - this was already noted in the original issue description.
I can add that I don't think the issues are the same. I get this behaviour and thought it was hibernate / standby / restore related but was on a train today and had an eclipse window disappear on me when the network dropped. Just re-running eclipse brings the original window back fully working (it also tries to start a new eclipse which fails as it is already using the workspace).
Every now and again it also doesn't reconnect, and I have to kill it and restart it, but it is rare enough for me to not be too worried about that.
I think that this is something to do with the MSRDC connection breaking when the network changes. I don't know then if this means that the connection is made via the wrong IP address. I also don't know how this would be controlled...
Sorry I didn't report this earlier, but I found on Monday that when all windows are gone, I just have to start a new xterm from bash (the most simple Wslg program I can think of), and everything pops up back. Some glitches but by clicking and wait that all event handlers reconnect, everything goes back to normal in 2 or 3 seconds.
I use Jetbrains' PhpStorm with at least 3 windows open.
It was a real pain as many services attached had to be killed/restarted before I found this by accident.
Hope it works for you, while this bug is fixed. I saved my days.
yes, I am aware if that except that xfce4-terminal pops up and is unresponsive and it is my main tool.
@hideyukn88 any insight about this issue? It's very easy to reproduce, just open a wslg app and disconnect from the Windows network, see the window disappear. You get a [07:40:23.894] <5>WSLGd: Run:108: pid 1289 exited with status 0 in stderr.log and a bunch of errors in wlog.log like:
[07:40:33:874] [579:579] [ERROR][com.freerdp.core.transport] - BIO_read returned a system error 11: Resource temporarily unavailable
[07:40:33:874] [579:579] [ERROR][com.freerdp.core] - transport_read_layer:freerdp_set_last_error_ex ERRCONNECT_CONNECT_TRANSPORT_FAILED [0x0002000D]
[07:40:33:875] [579:579] [ERROR][com.freerdp.core.transport] - BIO_should_retry returned a system error 32: Broken pipe
[07:40:33:875] [579:579] [ERROR][com.freerdp.core.transport] - BIO_should_retry returned a system error 32: Broken pipe
[07:40:33:875] [579:579] [ERROR][com.freerdp.core.transport] - BIO_should_retry returned a system error 32: Broken pipe
[07:40:33:875] [579:579] [ERROR][com.freerdp.core.transport] - BIO_should_retry returned a system error 32: Broken pipe
It seems the rdp client is restarted and the new one isn't able to manage the old windows. I'd say #1098 is the very same issue, a network change caused by going to sleep which leads to the same problem. But this is more easy to trigger and debug.
Disabling the WiFi-Adapter causes the windows to disappear. While re-enabling the adapter, the WSL's vEthernet adapter and teh vEthernet default switch seem to "disconnect" their "cable" ...
https://github.com/microsoft/wslg/assets/6409516/46f80042-be44-4cbe-9938-c64a5ff77aad
Interestingly, disabling not consistently causes the windows to disappear. But I could not determine what makes them stay.
Commenting to add to the noise (as well as follow), but this is happening to me whenever the network interface: a) sleeps, or b) changes (specifically, connecting to a VPN).
I don't necessarily mind reopening Emacs, but as @DmitryGrayscale pointed out, it's incredibly frustrating to lose open buffers when I'm knee-deep in a days-long bug hunting process.
This gets terrifically frustrating, especially given how inconsistent it is for me. Generally a network change will "disappear" my XWayland windows -- but not always. Sometimes running any simple X application (e.g., xeyes) will restore them, but sometimes neither the vanished windows nor that new app will display (though the all of processes are there, and logging -- at least on the Linux side of things -- indicates nothing unusual). If the behavior was consistent, it'd at least be a heckuva lot easier to work around.
I have the same issue. As a workaround I run xclock from the terminal, then my disappeared windows appear again.
I agree that running an x application after the windows disappear seems to mostly bring them back. I have also seen an application stop when the networking changes (most often on restore from hibernate); a guess is that that application does something graphical while the GUI is gone and causes a crash somehow.
It used to be possible to hibernate and resume without losing windows so something has changed. A possible place that could have changed though is Hyper-V... maybe this has changed what happens when network cables are disconnected?
Ideally since I can do this manually something would reconnect when it disconnects, and then the problem would likely be solved...