Open speller opened 3 years ago
@speller, thanks for reporting the issue. Do you encounter this issue at every attempt of sleep or hibernate? If you don't mind, would you please share /mnt/wslg/weston.log with us? thanks!
Hello, @hideyukn88,
This happens every night to me, let me share weston.log
of 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:
Same here, when I wake up my laptop my Intellij windows, running on WSLg, are gone.
@dmarcelino, if you are experiencing this issue after upgrading to the latest WSL/WSLg release from aka.ms/wslstorepage, please share core file from /mnt/wslg/dumps, thanks!
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!
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.
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
:
[01:39:17.163] xfixes selection notify event: owner 2097153
[01:39:17.163] our window, skipping
[01:39:17.166] Client: ClientGetAppidReq: pid:7356 appId:jetbrains-phpstorm WindowId:0x2
[01:39:17.167] Client: ClientGetAppidReq: pid:7356 appId:jetbrains-phpstorm WindowId:0x3
[01:39:17.169] Client: ClientGetAppidReq: pid:7251 appId:jetbrains-toolbox WindowId:0x4
[01:39:17.169] Client: ClientSysparam: filterKeys
[01:39:17.169] Client: ClientSysparam: toggleKeys:62
[01:39:17.169] Client: ClientSysparam: stickyKeys:90
[01:39:17.169] Client: ClientSysparam: caretWidth:1
[01:39:17.169] Client: ClientSysparam: highContrast
[01:39:17.169] Client: ClientSysparam: taskbarPos:(left:0, top:2088, right:3840, bottom:2160)
[01:39:17.169] Client: ClientSysparam: mouseButtonSwap:0
[01:39:17.169] Client: ClientSysparam: keyboardPref:0
[01:39:17.169] Client: ClientSysparam: dragFullWindows:1
[01:39:17.169] Client: ClientSysparam: keyboardCues:0
[01:39:17.169] Client: ClientSysparam: workArea:(left:0, top:0, right:3840, bottom:2088)
[01:39:17.169] Translated workarea:(0,0)-(3840,2088) at rdp-0:(0,0)-(3840,2160)
[02:39:15.687] unable to checkDescriptor for 0x5589d05863f0
[02:39:15.689] app_list_monitor_thread: stopRdpNotifyEvent is signalled. 1
[02:39:15.689] rdp_rail_notify_app_list(): rdp_peer 0x5589d053aa70
[02:39:15.689] inSync: 0
[02:39:15.689] syncStart: 0
[02:39:15.689] syncEnd: 0
[02:39:15.689] newAppId: 0
[02:39:15.689] deleteAppId: 0
[02:39:15.689] deleteAppProvider: 1
[02:39:15.689] associateWindowId: 0
[02:39:15.689] appId: (null)
[02:39:15.689] appGroup: (null)
[02:39:15.689] appExecPath: (null)
[02:39:15.689] appWorkingDir: (null)
[02:39:15.689] appDesc: (null)
[02:39:15.689] appIcon: (nil)
[02:39:15.689] appProvider: Ubuntu-22.04
[02:39:15.689] appWindowId: 0x0
[02:39:15.692] xfixes selection notify event: owner 2097153
[02:39:15.692] our window, skipping
[02:39:15.693] xfixes selection notify event: owner 2097153
[02:39:15.693] our window, skipping
[10:51:50.955] Client: ClientStatus:0x3f5
[10:51:50.955] - TS_RAIL_CLIENTSTATUS_ALLOWLOCALMOVESIZE
[10:51:50.955] - TS_RAIL_CLIENTSTATUS_ZORDER_SYNC
[10:51:50.955] - TS_RAIL_CLIENTSTATUS_WINDOW_RESIZE_MARGIN_SUPPORTED
[10:51:50.955] - TS_RAIL_CLIENTSTATUS_HIGH_DPI_ICONS_SUPPORTED
[10:51:50.955] - TS_RAIL_CLIENTSTATUS_APPBAR_REMOTING_SUPPORTED
[10:51:50.955] - TS_RAIL_CLIENTSTATUS_POWER_DISPLAY_REQUEST_SUPPORTED
[10:51:50.955] - TS_RAIL_CLIENTSTATUS_GET_APPID_RESPONSE_EX_SUPPORTED
[10:51:50.955] - TS_RAIL_CLIENTSTATUS_BIDIRECTIONAL_CLOAK_SUPPORTED
[10:51:50.955] Client HandShake buildNumber:22621
[10:51:50.969] Server AppList caps version:4
[10:51:50.969] appListProviderName:Ubuntu-22.04
[10:51:50.969] appListProviderUniqueId:670BBDB5-FACB-11E6-BD58-64006A7986D3
[10:51:50.989] Client: gfxredir_caps: length:28
[10:51:50.989] Client: GrfxCaps count:0xa
[10:51:50.989] Client: gfxredir_caps[0]: signature:0x53504143
[10:51:50.989] Client: GrfxCaps[0] version:0x80004 length:4 flags:0x0
[10:51:50.989] Version : RDPGFX_CAPVERSION_8
[10:51:50.989] Client: gfxredir_caps[0]: version:0x1
[10:51:50.989] Client: gfxredir_caps[0]: length:12
[10:51:50.989] Client: GrfxCaps[1] version:0x80105 length:4 flags:0x0
[10:51:50.989] Version : RDPGFX_CAPVERSION_81
[10:51:50.989] Client: GrfxCaps[2] version:0xa0002 length:4 flags:0x0
[10:51:50.989] Version : RDPGFX_CAPVERSION_10
[10:51:50.989] Client: gfxredir_caps[1]: signature:0x53504143
[10:51:50.989] Client: gfxredir_caps[1]: version:0x2000
[10:51:50.989] Client: gfxredir_caps[1]: length:16
[10:51:50.989] Client: gfxredir_caps[1]: supportedFeatures:0x0
[10:51:50.989] Client: gfxredir selected caps: version:0x2000
[10:51:50.989] Client: GrfxCaps[3] version:0xa0200 length:4 flags:0x0
[10:51:50.989] Version : RDPGFX_CAPVERSION_102
[10:51:50.989] Client: GrfxCaps[4] version:0xa0301 length:4 flags:0x0
[10:51:50.989] Version : RDPGFX_CAPVERSION_103
[10:51:50.989] Client: GrfxCaps[5] version:0xa0400 length:4 flags:0x0
[10:51:50.989] Version : RDPGFX_CAPVERSION_104
[10:51:50.989] Client: GrfxCaps[6] version:0xa0502 length:4 flags:0x0
[10:51:50.989] Version : RDPGFX_CAPVERSION_105
[10:51:50.989] Client: GrfxCaps[7] version:0xa0600 length:4 flags:0x0
[10:51:50.989] Version : RDPGFX_CAPVERSION_106
[10:51:50.990] Client: GrfxCaps[8] version:0xa0701 length:4 flags:0x0
[10:51:50.990] Version : UNKNOWN(657153)
[10:51:50.990] Client: GrfxCaps[9] version:0xb0101 length:4 flags:0x0
[10:51:50.990] Version : UNKNOWN(721153)
[10:51:51.000] xf_peer_adjust_monitor_layout:
[10:51:51.000] DesktopWidth:3840, DesktopHeight:2160
[10:51:51.000] UseMultimon:0
[10:51:51.000] ForceMultimon:0
[10:51:51.000] MonitorCount:0
[10:51:51.000] HasMonitorAttributes:0
[10:51:51.000] HiDefRemoteApp:1
[10:51:51.000] disp_monitor_sanity_check_layout:---INPUT---
[10:51:51.000] rdpMonitor[0]: x:0, y:0, width:3840, height:2160, is_primary:1
[10:51:51.000] rdpMonitor[0]: physicalWidth:597, physicalHeight:336, orientation:0
[10:51:51.000] rdpMonitor[0]: desktopScaleFactor:150, deviceScaleFactor:140
[10:51:51.000] rdpMonitor[0]: scale:1, client scale :1.00
[10:51:51.000] kbd_layout:0xe0010411 kbd_type:0x7 kbd_subType:0x2 kbd_functionKeys:0xc
[10:51:51.000] convert_rdp_keyboard_to_xkb_rule_names: matching model=pc105 layout=jp variant=(null) options=(null)
[10:51:51.004] Client ExecOrder:0x00000008, Program:dummy-entry, WorkingDir:(null), RemoteApplicationArguments:(null)
[10:51:51.004] Client ExecOrder launching dummy-entry
[10:51:51.004] launching 'dummy-entry'
[10:51:51.005] compositor: executing 'dummy-entry' failed: No such file or directory
[10:51:51.005] Client: ClientSysparam: filterKeys
[10:51:51.006] Client: ClientSysparam: toggleKeys:62
[10:51:51.006] Client: ClientSysparam: stickyKeys:90
[10:51:51.006] Client: ClientSysparam: caretWidth:1
[10:51:51.006] Client: ClientSysparam: highContrast
[10:51:51.006] Client: ClientSysparam: taskbarPos:(left:0, top:2088, right:3840, bottom:2160)
[10:51:51.006] Client: ClientSysparam: mouseButtonSwap:0
[10:51:51.006] Client: ClientSysparam: keyboardPref:0
[10:51:51.006] Client: ClientSysparam: dragFullWindows:1
[10:51:51.006] Client: ClientSysparam: keyboardCues:0
[10:51:51.006] Client: ClientSysparam: workArea:(left:0, top:0, right:3840, bottom:2088)
[10:51:51.006] Translated workarea:(0,0)-(3840,2088) at rdp-0:(0,0)-(3840,2160)
[10:51:51.028] xfixes selection notify event: owner 0
[10:51:51.028] Client AppList caps version:4
[10:51:51.028] Client AppList client language id: en_US
[10:51:51.028] Client ExecOrder program terminated
[10:51:51.028] app_list_monitor_thread: startRdpNotifyEvent is signalled. 0 - en_US
[10:51:51.028] rdp_rail_notify_app_list(): rdp_peer 0x5589d053aa70
[10:51:51.028] dummy-entry exited with status 255
[10:51:51.028] inSync: 1
[10:51:51.028] syncStart: 1
[10:51:51.028] syncEnd: 0
[10:51:51.028] newAppId: 1
[10:51:51.028] deleteAppId: 0
[10:51:51.028] deleteAppProvider: 0
[10:51:51.028] associateWindowId: 0
[10:51:51.028] appId: ubuntu-desktop-installer_ubuntu-desktop-installer
[10:51:51.028] appGroup: (null)
[10:51:51.028] appExecPath: env BAMF_DESKTOP_FILE_HINT=/var/lib/snapd/desktop/applications/ubuntu-desktop-installer_ubuntu-desktop-installer.desktop /snap/bin/ubuntu-desktop-installer
[10:51:51.028] appWorkingDir: (null)
[10:51:51.028] appDesc: Install RELEASE (Ubuntu-22.04)
[10:51:51.028] appIcon: 0x5589d04de410
[10:51:51.028] appProvider: (null)
[10:51:51.028] appWindowId: 0x0
[10:51:51.029] rdp_rail_notify_app_list(): rdp_peer 0x5589d053aa70
[10:51:51.029] inSync: 1
[10:51:51.029] syncStart: 0
[10:51:51.029] syncEnd: 0
[10:51:51.029] newAppId: 1
[10:51:51.029] deleteAppId: 0
[10:51:51.029] deleteAppProvider: 0
[10:51:51.029] associateWindowId: 0
[10:51:51.029] appId: kcachegrind
[10:51:51.029] appGroup: (null)
[10:51:51.029] appExecPath: kcachegrind -qwindowtitle %c
[10:51:51.029] appWorkingDir: (null)
[10:51:51.029] appDesc: KCachegrind (Ubuntu-22.04)
[10:51:51.029] appIcon: 0x7f630400bc00
[10:51:51.029] appProvider: (null)
[10:51:51.029] appWindowId: 0x0
[10:51:51.029] rdp_rail_notify_app_list(): rdp_peer 0x5589d053aa70
[10:51:51.029] inSync: 1
[10:51:51.029] syncStart: 0
[10:51:51.029] syncEnd: 0
[10:51:51.029] newAppId: 1
[10:51:51.029] deleteAppId: 0
[10:51:51.029] deleteAppProvider: 0
[10:51:51.029] associateWindowId: 0
[10:51:51.029] appId: firefox
[10:51:51.029] appGroup: (null)
[10:51:51.029] appExecPath: firefox
[10:51:51.029] appWorkingDir: (null)
[10:51:51.029] appDesc: Firefox Web Browser (Ubuntu-22.04)
[10:51:51.029] appIcon: 0x7f630400c290
[10:51:51.029] appProvider: (null)
[10:51:51.029] appWindowId: 0x0
[10:51:51.029] rdp_rail_notify_app_list(): rdp_peer 0x5589d053aa70
[10:51:51.029] inSync: 1
[10:51:51.029] syncStart: 0
[10:51:51.029] syncEnd: 0
[10:51:51.029] newAppId: 1
[10:51:51.029] deleteAppId: 0
[10:51:51.029] deleteAppProvider: 0
[10:51:51.029] associateWindowId: 0
[10:51:51.029] appId: Nautilus
[10:51:51.029] appGroup: (null)
[10:51:51.029] appExecPath: nautilus --new-window
[10:51:51.029] appWorkingDir: (null)
[10:51:51.029] appDesc: Files (Ubuntu-22.04)
[10:51:51.029] appIcon: 0x7f630403bf20
[10:51:51.029] appProvider: (null)
[10:51:51.029] appWindowId: 0x0
[10:51:51.030] rdp_rail_notify_app_list(): rdp_peer 0x5589d053aa70
[10:51:51.030] inSync: 1
[10:51:51.030] syncStart: 0
[10:51:51.030] syncEnd: 1
[10:51:51.030] newAppId: 1
[10:51:51.030] deleteAppId: 0
[10:51:51.030] deleteAppProvider: 0
[10:51:51.030] associateWindowId: 0
[10:51:51.030] appId: font-viewer
[10:51:51.030] appGroup: (null)
[10:51:51.030] appExecPath: gnome-font-viewer
[10:51:51.030] appWorkingDir: (null)
[10:51:51.030] appDesc: Fonts (Ubuntu-22.04)
[10:51:51.030] appIcon: 0x7f630405f1d0
[10:51:51.030] appProvider: (null)
[10:51:51.030] appWindowId: 0x0
[10:51:51.130] Pulse Audio Sink listener socket on /mnt/wslg/PulseAudioRDPSink
[10:51:51.132] Client: ClientGetAppidReq: pid:7356 appId:jetbrains-phpstorm WindowId:0x2
[10:51:51.132] Client: ClientGetAppidReq: pid:7356 appId:jetbrains-phpstorm WindowId:0x3
[10:51:51.132] xfixes selection notify event: owner 2097153
[10:51:51.133] our window, skipping
[10:51:51.134] Client: ClientGetAppidReq: pid:7251 appId:jetbrains-toolbox WindowId:0x4
[10:51:51.134] Client: ClientSysparam: filterKeys
[10:51:51.134] Client: ClientSysparam: toggleKeys:62
[10:51:51.134] Client: ClientSysparam: stickyKeys:90
[10:51:51.134] Client: ClientSysparam: caretWidth:1
[10:51:51.134] Client: ClientSysparam: highContrast
[10:51:51.134] Client: ClientSysparam: taskbarPos:(left:0, top:2088, right:3840, bottom:2160)
[10:51:51.134] Client: ClientSysparam: mouseButtonSwap:0
[10:51:51.134] Client: ClientSysparam: keyboardPref:0
[10:51:51.134] Client: ClientSysparam: dragFullWindows:1
[10:51:51.134] Client: ClientSysparam: keyboardCues:0
[10:51:51.134] Client: ClientSysparam: workArea:(left:0, top:0, right:3840, bottom:2088)
[10:51:51.134] Translated workarea:(0,0)-(3840,2088) at rdp-0:(0,0)-(3840,2160)
[10:58:04.896] xfixes selection notify event: owner 2097153
[10:58:04.896] our window, skipping
[11:00:03.954] xfixes selection notify event: owner 2097153
[11:00:03.954] our window, skipping
[11:01:45.640] xfixes selection notify event: owner 2097153
[11:01:45.640] our window, skipping
[11:08:25.630] xfixes selection notify event: owner 2097153
[11:08:25.630] our window, skipping
[11:08:56.103] xfixes selection notify event: owner 2097153
[11:08:56.103] our window, skipping
[11:29:11.158] xfixes selection notify event: owner 2097153
[11:29:11.158] our window, skipping
[11:30:35.009] xfixes selection notify event: owner 2097153
[11:30:35.009] our window, skipping
[11:30:35.010]
RDP clipboard_data_source_send new (0x7f62dc000bc0:published:fd 112) vs prev (0x7f62dc000980:cancel pending:fd 111): outstanding RDP data request (client to server)
[11:30:35.010] xfixes selection notify event: owner 2097153
[11:30:35.011] our window, skipping
[11:33:39.858] xfixes selection notify event: owner 2097153
[11:33:39.858] our window, skipping
[11:34:49.577] xfixes selection notify event: owner 2097153
[11:34:49.577] our window, skipping
[11:36:00.467]
RDP clipboard_data_source_send new (0x7f62dc000d10:published:fd 112) vs prev (0x7f62dc0008e0:cancel pending:fd 111): outstanding RDP data request (client to server)
[11:36:00.467] xfixes selection notify event: owner 2097153
[11:36:00.467] our window, skipping
[11:36:00.467] xfixes selection notify event: owner 2097153
[11:36:00.467] our window, skipping
[11:39:32.007] xfixes selection notify event: owner 2097153
[11:39:32.007] our window, skipping
[11:39:32.017] xfixes selection notify event: owner 2097153
[11:39:32.017] our window, skipping
The following apps are expected to be running but their windows have disappeared:
[10:51:51.132] Client: ClientGetAppidReq: pid:7356 appId:jetbrains-phpstorm WindowId:0x2
[10:51:51.132] Client: ClientGetAppidReq: pid:7356 appId:jetbrains-phpstorm WindowId:0x3
[10:51:51.134] Client: ClientGetAppidReq: pid:7251 appId:jetbrains-toolbox WindowId:0x4
There are no thread dumps when it happens.
Here are other logs related to the issue:
stderr.log
:
Errors from xkbcomp are not fatal to the X server
[10:51:49.275] <5>WSLGd: Run:108: pid 9850 exited with status 0, /init /mnt/c/Program Files/WSL/msrdc.exe msrdc.exe /v:9B94241A-8FA0-4C6D-83D1-29C53C161576 /hvsocketserviceid:670BBDB5-FACB-11E6-BD58-64006A7986D3 /silent /wslg /plugin:WSLDVC_PACKAGE /wslgsharedmemorypath:WSL\9B94241A-8FA0-4C6D-83D1-29C53C161576\wslg C:\Program Files\WSL\wslg.rdp
Error: debug scope named 'rdp-audio' is already registered.
Error: debug scope named 'rdp-audio-in' is already registered.
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Warning: Unsupported maximum keycode 569, clipping.
> X11 cannot support keycodes above 255.
> Internal error: Could not resolve keysym XF86FullScreen
Errors from xkbcomp are not fatal to the X server
The path in the log contains the /mnt/c
prefix to the system windows host file system. But I'm not using this prefix! The /mnt/c
directory is empty. I'm using the host file system mounts in the root of the linux file system:
Here is my wsl.conf
file contents:
[automount]
enabled=true
root=/
options="metadata,umask=22,fmask=11"
mountFsTab=false
@hideyukn88 It looks like WSLg is trying to restore the RDP connection but fails to do that because of the wrong path.
Versions:
WSL version: 2.0.0.0
Kernel version: 5.15.123.1-1
WSLg version: 1.0.57
MSRDC version: 1.2.4485
Direct3D version: 1.608.2-61064218
DXCore version: 10.0.25880.1000-230602-1350.main
Windows version: 10.0.22621.2359
After adding the /mnt/c/Program Files
symlink that points to the proper directory, WSLg windows remain visible and work well after waking from sleep.
@speller, thanks for your analysis. Regarding to /mnt/c
mount point used to relaunch msrdc.exe, this should be the mount within system-distro, not your user-distro. And the root path configuration in wsl.conf should only be effective for that distro. Please double check by entering system-distro by wsl --system
from WIndows's command prompt. Also looking at your weston.log, it seems msrdc.exe is relaunched. But it's possible out-of-sync with Linux side. Do you see msrdc.exe is running from task manager? But if adding the /mnt/c/Program Files
symlink helps, I might be missing something. Also ideally, sleep should not cause the disconnection of RDP, may I ask how your sleep is configured in your system? Is it hibernate, connected-standby or ordinal sleep? thanks!
@hideyukn88 Ah, you're right, the path should be from the system distro. The system distro uses the /mnt
prefix, I've checked this. I had a few times in a row when I started my laptop in the morning and all WSL apps had no windows while their processes were alive. After adding the symlink, I had a few times in a row when the apps were working fine in the morning. Maybe it was luck that they stopped disappearing. I will check this and try to do a better analysis.
Here are my power settings:
I don't know how to check the type of sleep. I know that there can be hibernation, but my machine is a laptop and maybe this is why I can't find anything in settings related to hibernation.
@hideyukn88 just faced this issue again. You're right, user distro has nothing to do with the path. The msrdc.exe process is running after waking up:
Could you suggest other diagnoses to do for the issue?
Also, I can see multiple msrdc processes when no WSLg windows are on the screen. Is it okay?
They all have the same startup command:
msrdc.exe /v:B76ECA63-3AB9-47EE-80B5-9E3798287035 /hvsocketserviceid:AEC83DCD-FACB-11E6-BD58-64006A7986D3 /silent /wslg /plugin:WSLDVC_PACKAGE /wslgsharedmemorypath:WSL\B76ECA63-3AB9-47EE-80B5-9E3798287035\wslg "C:\Program Files\WSL\wslg.rdp"
The same problem - all GUI windows are gone after restore from hibernation (not sleep in my case). For example, Google Chrome, IntelliJ IDEA windows are all gone (but processes are listed in 'ps'). It started after upgrade to WSL 2.0.0.0. Attached weston.log weston.log
The same problem - all GUI windows are gone after restore from hibernation (not sleep in my case). For example, Google Chrome, IntelliJ IDEA windows are all gone (but processes are listed in 'ps'). It started after upgrade to WSL 2.0.0.0. Attached weston.log weston.log
I have the exact same problem
Just faced this issue again on the OpenVPN connection. It happens not every time, but sometimes.
[13:29:35:329] [9:9] [ERROR][com.freerdp.core.transport] - BIO_read returned a system error 11: Resource temporarily unavailable
[13:29:35:332] [9:9] [ERROR][com.freerdp.core] - transport_read_layer:freerdp_set_last_error_ex ERRCONNECT_CONNECT_TRANSPORT_FAILED [0x0002000D]
[13:29:35:343] [9:9] [ERROR][com.freerdp.core.transport] - BIO_should_retry returned a system error 32: Broken pipe
[13:29:35:343] [9:9] [ERROR][com.freerdp.core.transport] - BIO_should_retry returned a system error 32: Broken pipe
[13:29:35:343] [9:9] [ERROR][com.freerdp.core.transport] - BIO_should_retry returned a system error 32: Broken pipe
[13:29:35:343] [9:9] [ERROR][com.freerdp.core.transport] - BIO_should_retry returned a system error 32: Broken pipe
[13:29:35:363] [9:9] [ERROR][com.freerdp.core.transport] - BIO_should_retry returned a system error 32: Broken pipe
[13:29:35:380] [9:9] [ERROR][com.freerdp.core.transport] - BIO_should_retry returned a system error 32: Broken pipe
[13:29:35:435] [9:9] [ERROR][com.freerdp.core.transport] - BIO_should_retry returned a system error 32: Broken pipe
I used to have this issue and for a while it's gone. However, the issue just comes back and is worse than before. Unlike before, the problem happens every day.
For emacs, I used to be able to use emacsclient to create a frame and activate the frame using AutoHotKey to bring back the GUI. Now, I cannot do this anymore as the newly activated GUI does not accept any mouse or keyboard input.
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!
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.
I have the exact same issue of GUI windows disappearing after sleep wakeup with old windows reappearing except in my case the application is pure gtk emacs. I have attached my weston.log Hope that helps.
WSL version: 2.0.6.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.25880.1000-230602-1350.main
Windows version: 10.0.22621.2428
It might have to do with the order of startup, I had the following shortcut set to run in task scheduler,
"C:\Program Files\WSL\wslg.exe" -d Debian --cd "~" -- /usr/bin/emacs
Event-Log: System Source: Power-Troubleshooter Event-Code: 1
And the same symptoms presented themselves, the frame was visible but unresponsive and I was unable to bring it to the foreground or focus it. The same issue with GUI apps disappearing after sleep can also be seen with 'xclock'.
uname -a gives,
Linux bhw-thinkpad 5.15.133.1-microsoft-standard-WSL2 #1 SMP Thu Oct 5 21:02:42 UTC 2023 x86_64 GNU/Linux
I am experiencing this issue as well. GUI windows are completely gone on wake-up, and I am unable to start the affected apps again, without rebooting my system or guessing the correct process to kill in task manager.
I am experiencing this issue as well. GUI windows are completely gone on wake-up, and I am unable to start the affected apps again, without rebooting my system or guessing the correct process to kill in task manager.
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.
@willieowens I can confirm, running a new GUI app process restores all disappeared windows in my case.
I am experiencing this issue as well. GUI windows are completely gone on wake-up, and I am unable to start the affected apps again, without rebooting my system or guessing the correct process to kill in task manager.
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.
I also noticed that the problem become more often. Before, it only happened when I close the lid of my laptop and then reopen it. But it happens whenever it when into sleep and wake up. I had upgraded the driver of NVIDIA GPU, the second GPU, two days ago. I wonder if that upgrade made the situation worse?
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.
I have the same problem. Processes are still shown with ps
, if I start a new terminal, the old ones come back together with the new one, but none of them (including the newly started one) is able to take focus it appears. I can bring them to the front, but they don't get focus. I can't even close them clicking the 'x' in the window (I can close them from the program bar by selecting the 'x' there).
Once I closed all my windows, I could then open a new one which worked as expected. I also noticed that the clock was off by over one hour - between the wsl clock and windows clock (not sure if this is always the case). I just did a sudo hwclock -s
, and that fixed it, but can't say if this is related to this issue or not.
I can confirm that the issue happens almost every time I connect to VPN using OpenVPN. This is really weird.
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.
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
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.
There's a 3rd party tool to mitigate this issue and keep X windows alive: https://github.com/nbdd0121/wsld.
Anybody know if something similar is available for Wayland users?
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.
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)
I am experiencing this issue as well. GUI windows are completely gone on wake-up, and I am unable to start the affected apps again, without rebooting my system or guessing the correct process to kill in task manager.
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.
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.
Yep - lost internet connection for a second, and the window disappeared, so it's not (just) sleep.
Been suffering this problem for a month now.
I am experiencing this issue as well. GUI windows are completely gone on wake-up, and I am unable to start the affected apps again, without rebooting my system or guessing the correct process to kill in task manager.
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.
This used to work for me but now (after windows updates??) does not work anymore.
I think the actual GUI process is gone after hibernate. Will update from 2.0.0 to 2.0.14 and report back.
This seems to be a duplicate of https://github.com/microsoft/wslg/issues/1092
Appreciate the work on WSL.
Yeah, seems to be the same issue. This one is a lot older, however (2021!).
workaround that works for me (WSL2g): each time after wake up I just execute gedit
in 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.
Yeah, seems to be the same issue. This one is a lot older, however (2021!).
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!
Emacs dying on any sleep event and ~70% of network switches is a true productivity killer.
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-backports
and 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.
I'm running the following versions:
WSL version: 2.1.1.0
Kernel version: 5.15.146.1-2
WSLg version: 1.0.60
MSRDC version: 1.2.5105
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22631.3085
And WSLg windows are now restored automatically on VPN connection or other connectivity changes in the majority of cases.
Same issue here. I am using Arch+wayland. It seems no efforts on this issue for a long time...
WSL version: 2.1.5.0
Kernel version: 5.15.146.1-2
WSLg version: 1.0.60
MSRDC version: 1.2.5105
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22631.3527
A wsl update fixed the problem for me.
wsl --update
A wsl update fixed the problem for me.
wsl --update
@schonbachler What version are you using? I think my wsl is the latest version (2.1.5.0/1.0.60), but the issue still exists.
wsl --update
Same with @seagle0128. Updating does nothing for me, already up to date.
A wsl update fixed the problem for me.
wsl --update
@schonbachler What version are you using? I think my wsl is the latest version (2.1.5.0/1.0.60), but the issue still exists.
WSL version: 2.1.5.0
Kernel version: 5.15.146.1-2
WSLg version: 1.0.60
MSRDC version: 1.2.5105
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22631.3593
I can't remember exactly, but i think i also updated the linux packages (apt-get update and upgrade). In any case, it works for me now and it didn't work before.
While the situation seems to have been improving for a while - I had a 'good' (50%??) chance of keeping my windows when switching networks, after recent updates it is now completely broken: any time my laptop goes to sleep (not even hibernate), all windows are gone on wakeup, re-appear after a second, but are unresponsive. So anytime I leave my laptop for a few minutes, I lose all windows, have to kill and then re-open them :(
wsl --version
WSL version: 2.2.4.0 Kernel version: 5.15.153.1-2 WSLg version: 1.0.61 MSRDC version: 1.2.5326 Direct3D version: 1.611.1-81528511 DXCore version: 10.0.26091.1-240325-1447.ge-release Windows version: 10.0.22631.3737
weston.log attached, which should cover several instances (e.g. starting at 18:04; 17;36; weston.log
Please let me know if there is any additional information I can provide
Same situation as @hiker. I am using Arch Linux on Thinkpad T14.
❯ wsl --version WSL version: 2.2.4.0 Kernel version: 5.15.153.1-2 WSLg version: 1.0.61 MSRDC version: 1.2.5326 Direct3D version: 1.611.1-81528511 DXCore version: 10.0.26091.1-240325-1447.ge-release Windows version: 10.0.22631.3737
I'm using Debian and it's still no good. Do you think the choice of Linux distro matter?
I'm using Debian and it's still no good. Do you think the choice of Linux distro matter?
I don't think so. I tried three Linux distros and got the same issue.
Mine versions are these, not sure if it's meaningful.
WSL version: 2.2.4.0
Kernel version: 5.15.153.1-2
WSLg version: 1.0.61
MSRDC version: 1.2.5326
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26091.1-240325-1447.ge-release
Windows version: 10.0.22631.3737
OpenSUSE Tumbleweed. One GUI app. It often survives sleep/resume, but occasionally still gets killed.
Same issue on WSL 2.3.12.0 and OpenSUSE. The processes occasionally survive sleep. Now after a recent WSL upgrade I also lose network connectivity about 50% of times.
Same issue, on openSuse Tumbleweed, the window is visible after sleep, but keyboard and mouse interactions with it do not work. Using Emacs pgtk build with wayland.
Environment
Steps to reproduce
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.