wslg: GUI session get killed on waking from sleep
Environment
Windows build number: 21390.1010
Your Distribution version: Ubuntu 20.04
Your WSLg version: 1.0.22
Steps to reproduce
- RUn a WSL GUI app
- Go to sleep for a night
- Wake up.
Expected behavior
All opened apps are here.
Actual behavior
All WSL apps get killed.
AFAIK, the root issue is that all network connections are killed on wake up/hybernate. The only workaround is to use vsocks/pipes. There’s a 3rd party tool to mitigate this issue and keep X windows alive: https://github.com/nbdd0121/wsld . Please implement the same.
About this issue
- Original URL
- State: open
- Created 3 years ago
- Reactions: 15
- Comments: 34 (3 by maintainers)
Try my workaround of opening another wslg all (I use Files (Ubuntu)) to bring the hidden windows back (in my case, always PhpStorm). It’s not ideal of course, but better than a reboot.
Even starting another wslg app (emacs -q) can indeed bring back the UI of my lost emacs session, but that session became unresponsive to keyboard and mouse inputs that I cannot use it all. Thus the workround is not helpful.
@willieowens I can confirm, running a new GUI app process restores all disappeared windows in my case.
I can confirm that the issue happens almost every time I connect to VPN using OpenVPN. This is really weird.
I am experiencing this issue (seems to have started the last week or two for me). I’m on the latest. Attached is my weston log. My /mnt/wslg/dumps folder appears to be empty.
I had open was two PhpStorm (Intellij IDE) windows. Left my computer for a bit after locking, came back a few minutes later and the windows are gone. When I try to re-open them (running
C:\Windows\System32\wslg.exe ~ -d Ubuntu /opt/phpstorm/bin/phpstorm.sh) nothing happens.However, if I open a different wslg app (in my case, “Files (Ubuntu)”) the PhpStorm windows re-appear!
weston.log
edit Sometimes when I first try to open PhpStorm the window doesn’t appear at all, and the workaround of opening another wslg app, such as “Files (Ubuntu)” works to get the window to show. Generally, if I restart my computer, PhpStorm will open fine on a fresh boot.
That’s true. It seems like this was fixed in https://gitlab.gnome.org/GNOME/gtk/-/issues/6335 but needs to be backported. Hurrah for Carlos!
Oh I feel you there brother. The realization came late to me, but for anybody else trailing this thread and just wants their beloved Emacs to not run away between sleep/network disconnects, uninstalling the emacs-pgtk version and
sudo apt install emacs-lucid/bookworm-backportsand voila. So if/until the fix gets backported this is what I’m using to get my Emacs hit.Golly I might just stick with the lucid toolkit and roll with Emacs as a daemon from now on. NixOS is using lucid as the default toolkit too.
Cheers,
Addendum: updating to wslg version 1.0.60 had no noticeable effect.
workaround that works for me (WSL2g): each time after wake up I just execute
geditin the console (start any UI app, I guess), and it brings up a new Gedit window (which I don’t use and just close) but also all other windows that weren’t visible.Microsoft store forcefully updated me from WSL version: 1.2.5.0 (where this bug wasn’t a problem) to WSL version: 2.0.9.0.
In order to close the unresponsive session, I have to use “wsl --shutdown”. I have a clunky work around by resorting to Windows task scheduler to close all GUI windows upon sleep/hibernation. It triggers “On event - Log: System, Source: Microsoft-WIndows-Kernel-Power, Event ID: 187” and runs the action "Start a program taskkill /IM “msrdc.exe” ". Now at least upon system resume I can open up Emacs GUI without previous unresponsive sessions cropping up.
Here’s some interesting behaviour, the work around above will not work with Emacs daemon clients (shortcuts are the ones automatically created upon installing Emacs-29 on Debian 12.
Works: “C:\Program Files\WSL\wslg.exe” -d Debian --cd “~” – /usr/bin/emacs
Does not work: “C:\Program Files\WSL\wslg.exe” -d Debian --cd “~” – sh -c “if [ -n "$*" ]; then exec /usr/bin/emacsclient --alternate-editor= --display="$DISPLAY" "$@"; else exec emacsclient --alternate-editor= --create-frame; fi” sh
Instead the new client GUI exhibits the same behaviour where it is unresponsive to keyboard and mouse inputs. I can also confirm that disconnecting from my WIFI network causes the same behaviour as if I put the computer to sleep or hibernate. I have a MediaTek MT7921 adapter. I would appreciate it if anybody else has found a better solution.
I can confirm this. Recently my laptop had no internet connection - when it finally could connect, my windows all disappeared (and the process of starting a new one, killing them all would solve the issue again)
Actually, it can happen when switching wifi networks too! I suppose switching wifi networks triggers some internal events similar to those triggered by connecting to a vpn.
Thus, in conclusion, I would bet that the true GUI killer is actually some kind of networking-related event, since suspending/resuming also toggles the power on your wifi device.
Emacs dying on any sleep event and ~70% of network switches is a true productivity killer. Not sure why this isn’t receiving more attention from the devs.
Anybody know if something similar is available for Wayland users?
After adding the
/mnt/c/Program Filessymlink that points to the proper directory, WSLg windows remain visible and work well after waking from sleep.I started getting this issue after upgrading to v2.0.0.0. When my laptop wakes up, all WSLg windows are disappeared. The corresponding linux processes are still alive.
For example, today my machine woke up at 10:51, here is the corresponding part of the
weston.log:The following apps are expected to be running but their windows have disappeared:
There are no thread dumps when it happens.
Here are other logs related to the issue:
stderr.log:The path in the log contains the
/mnt/cprefix to the system windows host file system. But I’m not using this prefix! The/mnt/cdirectory is empty. I’m using the host file system mounts in the root of the linux file system:Here is my
wsl.conffile contents:@hideyukn88 It looks like WSLg is trying to restore the RDP connection but fails to do that because of the wrong path.
Versions:
Hello, @hideyukn88,
This happens every night to me, let me share
weston.logof mine.I’m not sure if it’s related but I usually maximum the GUI window on the 2nd display, and I turn off all monitors before going bed. Also, I found sometimes a GUI window by WSLg disappeared when I turned off a monitor. The following log is from that moment.
Environment:
Log file