Seems to break interop about genie HOT 29 CLOSED

It's not a genie/bottle issue; the interop problems are this WSL bug: microsoft/WSL#4465

Basically, if you lose the WSL_INTEROP environment variable, any attempt to interop segfaults. Currently genie drops this envar because sudo et. al. drop it. It may be fixed when the fix for the above comes in, and it's already fixinbound; use the workaround given in that issue; or else you can grab the experimental version of genie which preserves the WSL_ variables from the outside environment from the envar-edition branch and build that.

Reported it in the first place, even.

from genie.

Try the new one at the head of the geniesh branch. 😊 It's a bit of a kluge, but it seems to work.

from genie.

The spaces shouldn't be an issue. I used it as following in my .zshrc.

if [ $INSIDE_GENIE ]; then
  # fix path in WSL
  export PATH="$PATH:/win/c/Program Files/VS Code/bin:/win/c/Windows"
fi

from genie.

I've opened up the wiki here for contributions. Add your good ideas as you like!

from genie.

genie -s runs your login shell inside the bottle; basically, Windows-side, wsl genie -s is your substitute for just wsl to get started, or for the shortcut you get to start a shell in the distro. It follows login semantics, and as such does not preserve the current working directory.

I guess that is the part of that gives problems
Maybe can be worked around if one can run the same bash scripts that the WSL default init does to configure everything??

from genie.

I think that /init is the file that have to be executed, but i don't know how, if you use nano in the file it looks like a bash script but i don't know enough

from genie.

It's not bash, /init: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped. However yes, it does do something or other. Unfortunately you can't call it manually - seems to get it's pid and exit if not something...

However, I poked around some more and found this microsoft/WSL#4465.

Woops, seems like @cerebrate is already aware of this - they commented there.

from genie.

Woops! Didn't notice you created the issue.
I'll probably just wait for the fix, keep getting sidetracked with this.

I assume there's more to it than just that environment variable? I exported it in the genie shell, but explorer wouldn't open inside the WSL2 workspace. Regardless, it'll probably be sorted in the next build!

from genie.

The environment variable points to a socket (under /run/WSL) the various inits use to talk to each other which is necessary for interop, but children of different inits don't necessarily point to the same socket; and it has to be the right one in order to work.

It's worked reliably for me so far using genie to clone the environment from whence the bottle is made, anyway. But I don't plan on investigating any more deeply until the official WSL fix to 4465 ships, as that's going to change and/or eliminate whatever I need to do in genie to make this work.

from genie.

@cerebrate, just wanting to follow up about this.

I've built and installed your envar-edition, but I'm struggling to get the environment variables to load into the new shell.

I see you put a systemd environment generator, does this work in your setup, or was it a WIP - from my understanding, they run too early to be of use? In particular, I don't get the INSIDE_GENIE variable at all.

Managed to get an environment variable through when genie succeeds. Basically just called

/usr/sbin/env INSIDE_GENIE=true /usr/bin/nsenter -t {systemdPid} -m -p /sbin/runuser -l -w INSIDE_GENIE {realUserName}

from genie.

Okay, this is a little involved because of the way the genie bottle works, so let me talk you through how it's supposed to work.

1. During the bottle startup, genie first executes /lib/genie/dumpwslenv.sh . That script grabs the three WSL environment variables and dumps them into the /run/genie.env file, so if that file exists and contains them, that bit worked.

2. Also during bottle startup, systemd executes the genie environment generator, which adds the envars from that file to the systemd environment. You can check if it's working by running systemctl show-environment, which should include INSIDE_GENIE and the three copied envars.

3. However, while on a regular system those would be inherited by login shells, nsenter puts us inside the bottle, but it doesn't start a process ultimately parented by 'systemd', which is where the third script (/lib/genie/readwslenv.sh) comes in...

...but making that run automatically for every shell or command executed is the bit I haven't quite finished yet, which is one of the reasons I haven't shipped the envar-edition. 😅 At the moment I'm sourcing that script from my .zshenv.

from genie.

As you'll see from the latest commit on that branch, it's easy enough to solve for -c, since I can just use a proxy script that adds the envars and execs the specified command; but that doesn't work for -s, which needs to spawn a login shell, and so far I've found no way to inject the script into a login shell from the outside.

from genie.

Yeah, my hack of exporting INSIDE_GENIE=true for the -s and -c was basically to let me conditionally source readwslenv.sh in my .zshrc - I sync my dotfiles across machines.

For reference, runuser has the -w flag, which is not heavily documented. It's basically the same as the su -w flag - it lets you whitelist variables to keep when calling -l.

I suppose you could source readwslenv.sh prior to nsenter and runuser, as I've done for INSIDE_GENIE. That is, call something like:

/usr/sbin/env INSIDE_GENIE=true WSLx=x WSLy=y /usr/bin/nsenter -t {systemdPid} -m -p /sbin/runuser -l -w INSIDE_GENIE,WSLx,WSLy {realUserName}

Overall seeing as nsenter breaks the systemd environment, that second step isn't doing anything, right?

from genie.

You probably don't need to use a conditional, actually - readwslenv.sh checks for the existence of /run/genie.env, so if the bottle isn't set up yet, it'll exit without doing anything. (On the other hand, if you use not-in-bottle-but-with-bottle shells, that's different.)

...or, I suppose, if some of those are non-WSL machines, but in that case, you could just use

if [ -e /lib/genie/readwslenv.sh ]
then
  source /lib/genie/readwslenv.sh
fi

to only source on machines with genie installed, and defer to the built-in conditional otherwise.

...not sure I understand your question. Which second step?

from genie.

I jump between in and out of bottle shells, so I prefer to just keep it dynamic - though I suppose I could just check for readwslenv on non-WSL machines... Which you just suggested as I'm typing this!

The second step I'm referring to is the systemd environment generator - it's not really used if you just source readwslenv, right?

I'm thinking of modifying genie to instead source the readwslenv stuff prior to creating a shell, so I can share them straight through with runuser -l -w WSLx - opinions on that?

from genie.

Ah, right. Yeah, it is -- it imports variables into the environment block for systemd and all its children, so without that, nothing systemd spawns will see the imported envars, including the user-session systemd and all its children.

It's unlikely that not having it would cause problems for most configurations most of the time, but still.

I had considered a similar concept, but I'm still poking at ways to avoid having to duplicate the list of environment variables to import, to simplify future or user-side customization. It'd be a simple enough change if there were a utility like env(1) which could read a list of environment variables from a file natively, but I've concluded I'm probably going to have to write that if I want it.

from genie.

Woops! I guess I don't need it personally because the only time I'd communicate back to windows is via a user shell, where I'm already sourcing readwslenv... Though I can certainly see why it's necessary!

From what I gather, it'd just be a matter of reading in readwslenv, and swapping new lines for spaces, then injecting it in as xyz in /usr/bin/env xyz?

from genie.

The last version of geniesh works perfectly in Arch, the problem is that PATH has to be set manually, otherwise is seamless

from genie.

You should be able to change that if you add PATH to the variables saved in the /lib/genie/dumpwsl.env script. (I didn't do so by default because I prefer to add the bits of the Windows path I want manually as required - mine's kinda long and only some bits of it are interop-relevant.)

from genie.

Is problematic with the current implementation, because the PATH include spaces because windows, and at the moment of inject the values, has various problems, and forcing to put " in /run/genie.env doesn't seem to fix it

from genie.

yea, good solution, and that fixes that finds some executables from outside WSL instead of use the ones inside

from genie.

Yeah, but if you want to use the windows ones over the linux ones, you'll need to reorder the path - I prefer native in wsl versus the windows ones.

from genie.

This tips would be a great add in the README

from genie.

I've opened up the wiki here for contributions. Add your good ideas as you like!

I can't seem to edit the wiki - at least not online?

from genie.

Should be fixed now.

from genie.

Now that microsoft/WSL#4465 is tagged as fixed in the last Insider Release, I guess that some things that genie does to keep interop could be dropped

from genie.

I just used genie 1.12 and don't work perfectly, PATH do not get windows dirs, but when you add the PATH it let you call explorer.exe, does not return segfault, but also that doesn't open explorer.exe

from genie.

Please try this with 1.16; if it still doesn't work, can you open it as a new issue rather than add to this one? Thanks.

from genie.

For anyone stumbling across this issue today, here's the definitive statement on the status of path, envars, and cwd:

https://github.com/arkane-systems/genie/wiki/A-note-on-environment-variables-and-cwd

Please open a new issue if that doesn't answer your questions.

from genie.