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.