-
Notifications
You must be signed in to change notification settings - Fork 818
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
Upgrade from 0.70.4 to 1.0 kills /tmp/.X11/X0 iff systemd is enabled #9158
Comments
Thank you for reporting this @g2flyer. Can you share the output of Also, /logs |
Hello! Could you please provide more logs to help us better diagnose your issue? To collect WSL logs, download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:
The scipt will output the path of the log file once done. Once completed please upload the output files to this Github issue. Click here for more info on logging Thank you! |
WslLogs-2022-11-16_10-36-23.zip |
Oh, didn't see that the collect was from bot and the real feedback requested was journalctl. Unfortunately, it will take some time to get that as i'm working right now in the problematic distro. however, i tried with a separate minimal vanilla 20.04 distro and in that one i actually do not get that problem, so race condition sounds quite plausible. Will update with journal log once i get a chance ... |
ok, now also the requested journalctl.log. Hope that helps .. |
I have the same issue (running Fedora 36). "journalctl -xe" says: "systemd-socket-proxyd[539]: Failed to get remote socket: Too many open files" whenever I run an X-command (eg. xterm). |
When run manually here is the output:
After enabling systemd, to have GUI apps working a link need to be setup, until a fix arrives:
This helps with having |
I can confirm the regression after upgrading WSL, and I also can confirm that the fix that @elsaco wrote works. |
|
Interesting. I wonder if you have other units installed that could explain this. What's the output of |
|
@OneBlue at least on my Ubuntu 22.04 -- not sure whether that's also distro @elsaco and @kovan are using ... -- i did have gdm running and, more importantly, once i disable gdm (and restart wsl) the socket survives the systemd start! |
I have the same problem, but with only one of my two WSL distro. Versão do WSL: 1.0.0.0 NAME STATE VERSION
After upgrading from 0.70.4 to 1.0.0 just the Ubuntu distro continuous open the X apps. And I also can confirm that the fix that @elsaco wrote works. |
That solved my problem! Thanks @g2flyer |
Something strange. |
Getting failures on these (Arch Linux, systemd 252.1)
Could it be related to a newer version of systemd? |
some workarounds to solve this problem sed -i 's/LoadCredential=/#LoadCredential=/' /usr/lib/systemd/system/systemd-tmpfiles-setup-dev.service
sed -i 's/LoadCredential=/#LoadCredential=/' /usr/lib/systemd/system/systemd-tmpfiles-setup.service
sed -i 's/LoadCredential=/#LoadCredential=/' /usr/lib/systemd/system/systemd-sysctl.service
sed -i 's/LoadCredential=/#LoadCredential=/' /usr/lib/systemd/system/systemd-tmpfiles-clean.service
sed -i 's/LoadCredential=/#LoadCredential=/' /usr/lib/systemd/system/systemd-sysusers.service also you may want to do this when upgrading systemd, so just make a pacman hook
|
Instead of modifying the unit files use overrides. This way unit files don't need to be edited every systemd upgrade. Example:
and |
Update on this issue: We have published a pre-release for WSL 1.0.1 which contain a fix that should work better: Bind mounting WSL will also create an empty |
The rename of I have a For both Win10 and Win11 manually creating the symlink as the old I can comment out LoadCredential items (via So seems like a regression for me, not overall - but now I'm in the reverse position where things were working, but these changes make it not work. I know things aren't universal between distros, so it happens. |
WSL 1.01 did not fix the X11 issue on my end.
|
The best solution to this problem (for me) is to support LoadCredential option in systemd support. |
i can confirm that with 1.0.3 enabled gdm does not prevent running X anymore. However, i noticed that gdm actually doesn't properly start automatically (but i can successfully start it manually after a boot). Looking at the journalctl it seems it's caused by permission issu on BTW: after updating to 1.0.3 it seems also windows was in a funky state that \wsl.localhost\Ubuntu was accessible only as Administrator. Shutting down and restarting WSL didn't help, only a reboot of win11 proper remediated this ... |
Upgrading to 1.0.3 did not fix for me, I still need to clear
To expand on this
may need to |
Version
10.0.22000.1219
WSL Version
Kernel Version
5.15.74.2
Distro Version
Ubuntu 22.04
Other Software
No response
Repro Steps
start distro with systemd enabled in
/etc/wls.conf
using powershellwsl.exe
and run X-application, say xtermExpected Behavior
directory
/tmp/.X11
should contain aX0
socket and Xapps work.Actual Behavior
DISPLAY
var is defined correctly as:0
but directory is/tmp/.X11
is empty (whereas if systemd is disabled it contains aX0
socket and Xapps work) and naturally commands such asxterm
fail withxterm: Xt error: Can't open display: :0
.Also note that if i log into system partition before starting distro, i see
/tmp/.X11/X0
and /mnt/wslg/.X11-unix/X0` but it gets wiped out (presumably by systemd) once distro starts ...This looks closely related to issue #9126: Seems while 0.70.8 did not have the issue with
/tmp/.X11
, it had other systemd setup issues and probably in an attempt to fix the broader issue the original problem resurfaced?The behaviour is also similar to microsoft/wslg#880 but as that was for version 0.70.4.0 which for me worked it must be a different issue (though maybe same root-cause?)
Diagnostic Logs
wsl-logs.zip
The text was updated successfully, but these errors were encountered: