os.environ['LOGNAME'] not defined

[ahupp]

Windows version (build number):
22000.556

Linux distribution:
Ubuntu 22.04

Kernel version:
5.10.102.1-microsoft-standard-WSL2

Genie version:
genie 2.3

Describe the bug
I am trying to start genie when WSL boots using the new-ish boot command feature in wsl.conf. This fails because the LOGNAME environment variable has not been set yet:

Traceback (most recent call last):
  File "/lib/python3.10/runpy.py", line 196, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/lib/python3.10/runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "/usr/lib/genie/genie/__main__.py", line 904, in <module>
  File "/usr/lib/genie/genie/__main__.py", line 862, in entrypoint
  File "/lib/python3.10/os.py", line 679, in __getitem__
    raise KeyError(key) from None
KeyError: 'LOGNAME'

Confirm that you are running inside the bottle:
N/A

To Reproduce

/etc/wsl.conf looks like this:

[boot]
command = "echo start $(date) >> /root/genie.log; /usr/bin/genie --initialize >> /root/genie.log 2>&1; echo end $(date) >> /root/genie.log"

Run wsl --shutdown, restart it, then note that a) genie -r reports "stopped", and b) the above stack is in the log file.

[NyaMisty]

Simply export LOGNAME="XXX" can solve the issue.
The default environment in [boot]->command is the following:

declare -x NAME="DESKTOP-697LVJS"
declare -x OLDPWD
declare -x PWD="/"
declare -x SHLVL="1"
declare -x WSL2_GUI_APPS_ENABLED="1"
declare -x WSL_DISTRO_NAME="UbuntuWSL2"
declare -x WSL_FEATURE_FLAGS="1"

So I suggest you use a script instead to wrap these things:

#!/bin/bash

echo "---------- WSL booted at $(/bin/date +'%Y-%m-%d %H:%M:%S') ----------" >> /var/log/genie.log
echo "Environments:" >> /var/log/genie.log
declare -px >> /var/log/genie.log
export LOGNAME='misty'
export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:$PATH
/usr/bin/genie -v -i >> /var/log/genie.log 2>&1
echo genie returns: $? >> /var/log/genie.log

[ahupp]

I did indeed define LOGNAME to work around this, but it was surprising behavior and took a little digging to figure out what was wrong, hence the bug report.

[NyaMisty]

Yup I know, I used your method to debug it too. But it should be a python issue actually. Quite happy to know that there's people doing exactly same thing ;)

[cerebrate]

Yeah, it turns out there are some... issues... with getting the original user. genie proper has to run setuid (via the setuid C executable and exec method) to function, but that means that getuid() isn't useful for getting it, and the normal method I'd use, os.getlogin(), requires that systemd-logind or an equivalent already be running to track login sessions before it can report anything, so that doesn't work either. LOGNAME wasn't my first choice, just the only one I had handy... and if not all distros set it by default (I'm a little surprised at Ubuntu dropping it), I'm not sure how I'm going to get that.

Thoughts welcome? 😬

[cerebrate]

...and, naturally, the moment I bitch about the problem, I come up with a solution to said problem.

Fix will be in 2.4.