-
Notifications
You must be signed in to change notification settings - Fork 840
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
wsl executes any command specified/starts shell before systemd has initialized, when starting instance #8886
Comments
Still happens under 0.68.2. |
IMO It might lead to undesirable and longer boot time. Some Systemd services can hold the distro from coming up for a really long time, For e.g. systemd-networkd holds the system from becoming 'ready' until the default interface gets an IP address from the DHCP server. You might want to run apps that do not depend on systemd to just work like before without waiting for A better solution could be to introduce a new flag maybe $ wsl -d <distro> --wait-for-systemd <command> We also have to think about what happens when systemd is not enabled within the distro, should wsl let the command run or give a friendly error saying systemd is disabled? |
Hrm. I'm not sure that's sufficient, because on one hand, there are apps that optionally depend on systemd and will behave differently with a partial-systemd (and bits of other services, dbus &c.) than they would with no systemd; and on the other hand, even apps that don't care about systemd per se may depend on things that systemd would then change out from underneath them, such as binfmts, sysctl parameters, securityfs rules, etc. ad naus. For example, systemd does a whole bunch of filesystem mounting and altering on the assumption that non-startup things aren't running at the same time - even an app that doesn't know anything about systemd may protest if /tmp suddenly switches out from beneath it in mid-execution, for example. This is also likely to include things like WSLg (per however #8888 shakes out), the state of the user runtime directory and overall user session (per however #8842 and #8918 work out), and so forth. So while I do recognize your valid point here, I think that on the whole allowing these early-running commands (certainly by default - I might propose the opposite flag On the other hand, this has interesting synergies with #8854 . I think we can probably agree that the two good options for just throwing out
On this, I'd say that all systemd-related flags, be they |
I see, we should keep things intuitive here. The user would expect systemd services to have completed their job before a shell is provided to them. If booting is terribly slow, they should be able to use The race conditions have already seeded a lot of problems which does not look like they have the same issue underneath at the glance making them hard-to-debug. We should not let Should we ask users to provide the details about mount/services on their system with debug logs (if systemd is enabled) ? |
|
For my systemd-enabling hacks, I have generally been asking for the output of a |
related: #11078 |
Is your feature request related to a problem? Please describe.
When a WSL instance with systemd support enabled is started (either with
wsl
orwsl <command>
), the shell inside the instance is started immediately, without waiting for systemd to have initialized (reached running state) and indeed without even waiting for the system dbus to be available. This is far earlier than native Linux provides a login prompt (getty.target and systemd-logind.service are both called upon by multi-user.target.)This means that if you are using systemd support in a way that involved heavy use of systemd services (and commands relating to same), there is a good chance that initial commands will fail. To pick a trivial example,
wsl systemctl is-system-running
usually errors out unless the WSL instance has already started.Describe the solution you'd like
When systemd support is enabled, by default, wsl.exe should hold any further actions (executing commands or starting shells) until systemd has reached the running or degraded state (as described by
systemctl is-system-running
) to ensure commands behave as they would on native Linux and novel failure modes aren't introduced.(This should be overridable for debugging purposes, ideally with a wsl.exe command-line option; a suitably lengthy or configurable timeout might also be useful.)
Describe alternatives you've considered
For compatibility with WSL as-it-is, this could be an option to be enabled in /etc/wsl.conf.
The text was updated successfully, but these errors were encountered: