Genie should not break outside-bottle environment while running by unmounting binfmt_misc about genie HOT 7 CLOSED

Having not had much luck in fixing this without reintroducing one form or another of the error it was introduced to eliminate, it appears Microsoft releasing their own systemd support has eliminated the problem (in newer versions of WSL, anyway) by eliminating the need to futz with binfmts at all.

Which is a cheap way out, but I'm going to take it, I'm afraid, given that said support has put a horizon on genie's long-term life anyway.

from genie.

Point of clarity:

It doesn't break WSL interop outside the bottle unless something else is wrong with your system. binfmts aren't namespaced; only the configuration filesystem for the feature is as part of the mount namespace.

So while you can't modify the state of your binfmts outside the bottle, any binfmts configured inside the bottle will be active outside and should work just fine. If they don't, you've got another problem.

from genie.

Maybe "break" is the wrong word.

The issue is that genie first unmounts /proc/sys/fs/binfmt_misc, then sets up the bottle namespace and lets systemd mount it itself. Thus, after bottle initializiation and outside of the bottle, /proc/sys/fs/binfmt_misc remains unmounted and programs that rely on it being mounted will fail.

One such example: wslvar tries to grep /proc/sys/fs/binfmt_misc/WSLInterop for the enabled flag, which causes grep to print a file not found error and wslvar to print an annoyinig warning message.

from genie.

On a freshly installed Ubuntu-20.04 WSL image with genie 2.3:

First without genie:

>wsl --shutdown
>wsl
$ genie -b
no-bottle
$ wslvar USERPROFILE
C:\Users\Elberet
$ grep binfmt_misc /proc/self/mounts
binfmt_misc /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0

And after genie has booted the bottle:

$ genie -i
Waiting for systemd....!!
$ genie -b
outside
$ grep binfmt_misc /proc/self/mounts
$ wslvar USERPROFILE
grep: /proc/sys/fs/binfmt_misc/WSLInterop: No such file or directory
WSL Interopability is disabled. Please enable it before using WSL.

from genie.

Hm.

I'm going to think about this one.

To clarify why I'm going to think about this one, it's because this feature will make it easier for people to do something I really don't want them to do, namely operate outside the bottle with genie running. That wasn't something I expected people to try and do deliberately, and in fairness to that assumption, most of the cases I've seen where they have been doing it have been in error.

Because here's the thing: genie uses a container-light setup for the bottle, but it's a really leaky abstraction. It gets the pid and mnt namespaces it needs to make systemd run happily, and AppArmor support uses its own AA namespace to avoid contaminating other distributions, but in the interests of maintaining usability/simplicity, it shares all the others. And even if it didn't, there would still be a lot of things that leak even between distros (all the networking config, sysctl values, the actual implementation of binfmts, and on and on), and the list of things that leak between outside and inside the bottle is even worse.

This is why the warning that using genie in multiple distributions simultaneously is there, because they'll mutually interfere, and likewise that warning about how anything that needs systemd or a systemd-powered service (such as dbus) will fail unpredictably when executed outside the bottle. There's always been a tacit design implication that outside-the-bottle is left there as a life-support system for inside-the-bottle, not intended to continue as an environment in itself.

So I must contemplate whether this is a usage worth supporting/implicitly endorsing, or whether I wouldn't be better off just adding a much more explicit DO NOT DO THIS instruction to the documentation.

from genie.

Fair enough, my bashrc actually contains a block to get me into the bottle by default.

This is more about cases where programs interact with WSL from the Windows side. Such tools will expect a 'standard' WSL environment, not a heavily customized userland in a systemd-controller namespace, and in my humble opinion, breaking that expectation on purpose is not a good idea.

Genie should not force users to choose between it and, for instance, the VSCode WSL remote plugin.

from genie.

That's a very good point. (And one I probably undervalue, since I tend to use the Linux-native VS Code from its snap.)

I won't be making changes for this in 2.4 (which has been delayed long enough already), but I'm going to think seriously about what can or can't be supported in 2.5.

from genie.