-
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
[0.70.8] masking systemd-tmpfiles-setup/systemd-tmpfiles-setup-dev breaks things elsewhere #9126
Comments
I think it broke php-fpm too.
|
Thank you for the detailed issue @cerebrate. This change was indeed made to resolve #9038. Under the hood WSL's Injecting a systemd unit via By injecting something like this:
We can actually have the systemd unit create the symlink itself, which I like because as long as WSL's init has already created the symlink before, it will either be there because |
Thanks for the detailed response, and apologies for my lack of earlier response, having had to step away from things previously this week. Unfortunately, while this is kinda-sorta fixed for me in 1.0, there are still some caveats.
Which seems redundant/confusing. Given my druthers, I'd rather keep the bind mount and drop the symlink, on the grounds that a read-only bind-mount is less likely to be accidentally damaged; I updated my own code to do that after @benhillis 's comment here: But move the bind mount to the post-systemd-tmpfile-setup.service point. Should be no more complicated a generator.
|
Thank you for the followup @cerebrate. To give a bit more context on why we took the systemd-tmpfiles override instead of injecting a new systemd unit:
That's why we went for the systemd-tmpfiles override. Since creating the symlink is atomic, there will either be a symlink or a bind mind at any given time, even if the systemd boot times out (but clearly it's not a perfect solution as you pointed out). Having a deeper look at systemd-tmpfiles's documentation, this might help: WSL currently creates Unfortunately, this does make the assumption that the X11 socket deletion is configured in |
Aha! From that perspective, that makes sense. (I confess I did not know that there was a delay for systemd to start - hence my creation of #8886 - because evidently my hardware is old and/or loaded enough that I always get control of the distro before systemd, or even the system dbus, have properly started. That was my main motivation for putting delays for a full startup into bottle-imp. To illustrate:
that's my WSL startup, all of which code presumably starts after the in-built timeout, and where each Considering the X11 socket deletion, it looks like |
There's a regression in 1.0.1 which no longer creates the symlink; the race condition is once again mounting /tmp over the existing bind mount. |
Indeed there was! We just published WSL 1.0.3 (pre-release) which addresses the /tmp mount issue. This release adds logic to inject a new unit (inspired from @cerebrate's suggestion) to recreate the bind mount if it's not accessible anymore. To summarize, there are now three layers of protection for the X11 socket:
Couple notes:
|
So that's why my secondary x server is breaking. Because someone decided to randomly make |
Has anyone tried wsl 1.0.3 and does it fix WSLg when systemd is enabled ? |
I've tried 1.0.3 and wslg does work for me with systemd (although see also my observation in #9158 (comment) on some permission issue with gdm auto-start) |
looks like my wsl updated itself to 1.0.3 and i'm able to use WSLg with systemd enabled now, so great success as far as i'm concerned. |
WSLg worked fine with systemd enabled before 1.0.3. You need to run a distribution that is configured to be compatible with it. Such as the newer Ubuntu 22.10 release with the WSL packages installed. You can look at projects like genie or distrod for the different workarounds needed to get systemd working with WSL. You don't need those full projects, but the configuration changes they make such as the The problem is, WSL2 is trying to act as both the init process/service manager (like systemd) and a system container manager in the docker or LXD vein. But it isn't following standards. Instead it is trying to forcibly change configuration and system setup without knowing how the guest system is set up or what it requires. Whatever the true intent is, it feels like a clumsy version of embrace, extend... and some other word. |
@AndASM: If you need to write in |
Thanks @OneBlue! I appreciate it. Fortunately I already know, and have implemented that. (But I much prefer people repeat answers if they think it hasn't been, rather than not answer and leave someone stuck and lost. So genuinely, thank you!) I created a separate issue (#9303) for the discussion of how making |
Version
WSL version: 0.70.8.0
WSL Version
Kernel Version
5.15.74.2-20221105-1-microsoft-custom-WSL2+
Distro Version
Debian sid
Other Software
No response
Repro Steps
After installing WSL 0.70.8, WSL appears to inject a generator-based masking of the systemd-tmpfiles-setup.service and systemd-tmpfiles-dev.service, as can be seen by the contents of
/run/systemd/generator-early
:I presume this is intended to solve the issue listed in the release notes as "Ensure /tmp/.X11-unix is not cleared by systemd [GH 9038]".
While this does solve the issue of systemd-tempfiles-setup.service removing the contents of
/tmp/.X11-unix
(although not the mount-order-based issue with .X11-unix, the problem is that it also breaks all the unrelated functionality of that unit, including that added by other packages (such as Ceph) after the fact.That unrelated functionality includes a lot of distro self-repair functions even other than cleaning up trash, including setting up and properly permissioning various directories under
/run
and/var
, and properly setting up initial conditions for polkit, quotas, systemd-journald, systemd-logind, systemd-networkd, systemd-machined, systemd-resolved, systemd-udevd, etal.In short, while not fatal in the short term on a simple system, in the long term on a complex system, this is begging for hard to diagnose errors.
(I've had to clean up some temps from interrupted operations and fix directories not created or with incorrect permissions in
/run
myself, and while my usage may be atypical, it's not extraordinary.)Expected Behavior
All the trash cleaned up, directories and links created, and permissions set as per the contents of
/lib/tmpfiles.d
, with the possible exception of/tmp/.X11-unix
.(I would also like to suggest as a possible solution, since it is possible to inject generator-based files into
/run/systemd/generator.early
, instead injecting a unit file into/run/systemd/generator
to bind mount/mnt/wslg/.X11-unix
over/tmp/.X11-unix
, configured to run after systemd-tmpfiles-setup.service? (Presumably also removing the current component that mounts/tmp/.X11-unix
) This should have the same ultimate effect where #9038 is concerned, and would also fix the mount race problem described in the comments to #8888.I only have a user's-eye view of WSL, but this is the approach I use in the current version of bottle-imp , and it seems quite effective, although ironically broken by this fix in 0.70.8.)
Actual Behavior
No actions configured in
/lib/tmpfiles.d
are executed.Diagnostic Logs
No response
The text was updated successfully, but these errors were encountered: