Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

X11 drops out when network changes #4675

Closed
pbecotte opened this issue Nov 13, 2019 · 16 comments
Closed

X11 drops out when network changes #4675

pbecotte opened this issue Nov 13, 2019 · 16 comments
Labels

Comments

@pbecotte
Copy link

  • Your Windows build number: 19018.1

  • What you're doing and what's happening:
    Environment

  1. Running Pycharm inside my WSL2 installation.
  2. Using Mobaxterm to launch the session and be the x11 server.
  3. Have export DISPLAY=`grep -oP "(?<=nameserver ).+" /etc/resolv.conf`:0 in my .bashrc.
  4. Happy to share any other settings that may be useful

Issue
Whenever I connect to a network, my x11 session ends. The windows simply dissapear from view, and 20 or 30 seconds later the prompt in my terminal shows $ to show that its ready for new input. There's no error output, just the last app ending.

This is not 100% of the time (had to cycle airplane mode twice to get it to happen just now of course), but the vast majority. When I get on the train in the morning, I won't bother opening my IDE until I can get my wifi working since I know it will crash whenever that happens.

I figure this is related to the networking/dns setup in some way (I found out the hard way that I can't run a caching dns server and wsl2 at the same time a while back), but am not sure where to troubleshoot beyond that (especially being a linux guy and having basically 0 windows sysadmin experience)

@karuboniru
Copy link

Same here, this happens randomly.And it seems that X11 applications won't be killed then (which should usually happen X applications is disconnected to XServer).

This happends on both VcXsrv and X410 here.

@therealkenc
Copy link
Collaborator

Rephrasing this one in terms some CLI networking scenario (ssh,sshd lets say) will probably get more eyeballs. Going to be spiritually dupe one of the several VPN / "my network changed" submissions.

@edburns
Copy link
Member

edburns commented Jan 23, 2020

Another problem. If you are using VS Code on the WSL side, connected with the WSL "Remote" extension (in this case to your own darn machine), and the connection drops, VS Code gets wonky. I've even seen it crash in this case.

@edburns
Copy link
Member

edburns commented Jan 24, 2020

In my case, the most fundamental problem was my Surface Dock losing and re-establishing the network connection with its wired ethernet port. I worked around this by using either WiFi, or the USB/Ethernet adapter. But I was still wanting to use the ethernet port on the dock. I found these resolutions:

I only did these steps ten minutes ago, so let's see if they resolve the random disconnect issue.

Update: 06:08:51 later and the connection has not dropped, so I think these steps solved the dock problem, FWIW.

Of course, being able to use a localhost for X is a better option.

@itspers
Copy link

itspers commented Sep 4, 2020

Same problem - working remotely under unstable wifi, which drops and connects periodically, and gui windows just disappear time to time :(

@anishsane
Copy link

Same problem.
Hitting this bug if wifi disconnects and I switch to mobile hotspot or vice versa.
Is there a simpler way, via say port forwarding to forward the windows X server port to Linux and use DISPLAY="localhost:0" ?

@neodarksaver
Copy link

Same issue. I use terminator on WSL2 with X server. On any network change (connect/disconnect to vpn, moving to new AP, docking/undocking), the terminator window just disappears.

@nbdd0121
Copy link

I wrote a workaround that uses vsock to bypass the X11 drop caused by TCP reset: https://github.com/nbdd0121/x11-over-vsock.

@rommeswi
Copy link

As of 2021, the bug persists and is obnoxious as hell.

@JanzenJohn
Copy link

JanzenJohn commented Aug 22, 2021

Your hostname changes when you connect to a network

In your hostsfile(/etc/hosts) is an entry something like this (on linux)

127.0.1.1 YourHostname

however connecting to a network (for example using network manager) changes your hostname to

YourHostname.YourDomain

For networkmanager you can change this in /etc/NetworkManager/NetworkManger.conf

by adding

[main]
plugins=keyfile
hostname-mode=none

Idk what wsl uses by default though (I had this issue on hardware, using NetworkManager)

So maybe look into finding what program manages connections on wsl ?

@JanusDC
Copy link

JanusDC commented Jan 27, 2024

I am having the same issue in Windows 11. There is still no solution to this bug opened 4 years ago?

@chanpreetdhanjal
Copy link

Hi. Can you please collect networking logs by following the instructions below?
https://github.com/microsoft/WSL/blob/master/CONTRIBUTING.md#collect-wsl-logs-for-networking-issues

@JanusDC
Copy link

JanusDC commented Feb 8, 2024

Here it is.
WslLogs-2024-02-08_18-27-48.zip

I started the log, I opened a PDF in Zathura using WSLg, I disconnected my wifi and reconnected again, Zathura GUI was lost (but still running according to ps on my Linux), and stoped the log.

@OneBlue
Copy link
Collaborator

OneBlue commented May 14, 2024

@pbecotte: It looks like you're overriding $DISPLAY to use a network based X server, which explains the symptoms you're seeing.

Do you see the same behavior if you use wslg instead ? If so, please collect /logs

@pbecotte
Copy link
Author

Wslg didn't exist when I opened this ticket :) In the four years since I opened this wasg came out, which I used for a while, and jetbrains gateway came out, which is my current approach. I believe this happened with wslg as well, but not as often- but I would no longer be able to provide logs etc since I have run anything other than a 2fa browser over x11 in years.

@OneBlue
Copy link
Collaborator

OneBlue commented May 15, 2024

Ok no problem !

Closing the issue since this scenario would most likely be solved via wslg.

@OneBlue OneBlue closed this as completed May 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests