systemd and inevitable leakage between distros

[cerebrate]

Is your feature request related to a problem? Please describe.
Less a problem but a potential problem: Linux namespaces, such as separate one distribution from another under WSL, aren't particularly solid or all-encompassing. This poses a plethora of potential problems for running systemd in multiple WSL distributions at once on the same machine, since they will each believe they have sole ownership of, say, sysctl values, network configuration, binfmts, AppArmor profiles, kernel module loading, and probably half-a-dozen other things I haven't run into myself yet, some of which currently require custom kernels but many of which are accessible with the standard one.

This sort of situation where one systemd can change bits of the system's parameters around behind another systemd's back is just asking for obscure and impossible-to-diagnose issues.

Describe the solution you'd like
Perhaps for safety only one distribution with systemctl support enabled should be permitted to run at any given time?

Describe alternatives you've considered
Document a warning and embrace the chaos?

Additional context
None.

[benhillis]

This was a consideration. Bad things will happen if multiple distros, for example, try to start sshd on port 22. I'm currently operating under "embrace the chaos and fix the dangerous outliers" mode, but your points are all valid.

[cerebrate]

Works for me! ;)

I've just seen a few reports here from people bitten by it in minor ways, so thought it was worth laying out there.

[cerebrate]

@benhillis : speaking of binfmts as the example of this that came up in another issue while I'm here anyway, I've noticed that the kernel command line includes systemd.mask=systemd-binfmt.service. I've noticed that in my (Debian sid) installation, this doesn't appear to have any effect; there's no visibility of this in the output of systemd-debug-generator, and systemd-binfmt.service activates and runs normally.

Not sure what's up with that, but I'm guessing it may be the reason behind #8843 etsim.

[benhillis]

@cerebrate - I think you're right, let me play with this a bit more. I think there are differences between different distros on how they handle the binfmt service.

[cerebrate]

FWIW, the three things I have had to fix up consistently with systemd running (and which seem to still be the case using native support rather than genie) are

• the binfmt for WSL interop (adding that config file),
• the /tmp/.X11-unix/X0 symlink for WSLg (which systemd-tmpfiles wipes out on startup, so I add a config file to have it recreate it), and
• overriding [email protected] to bind-mount /mnt/wslg/runtime-dir atop the systemd-created runtime directory when the uid matches (otherwise Wayland clients don't find the server, and there may be other side effects to having two xdg-runtime-dirs that I'm not aware of).

[advnpzn]

I know am late, but the thing is I noticed an issue (maybe) in two of my WSL instances running with systemd at the same time prompted me to check for answers and I came upon this thread.

So I have systemd enabled for two WSL2 instances.

In one WSL, running systemctl status --user is working.
But in the other instance, the same command shows Failed to connect to bus: No such file or directory.

I just wanted to see whether the problem I'm having would suit in the category of problems mentioned here.