Raising priority - the dbus daemon for user sessions won't autostart unless DISPLAY is set. This is really bad when using Wayland apps, which work without DISPLAY but will have key functionality break (like dconf settings in gedit).

Braindump on this:

Sommelier/xwl currently set DISPLAY in the systemd user session, then extract this and set it in /etc/profile.d/{sommelier,xwl}.sh

/etc/profile.d is sourced by /etc/profile. This is only sourced by bourne-compatible shells, i.e. not fish or zsh.

Other options I've thought about:
1) PAM module. There is no existing PAM module that can set an environment variable from a script. We'd have to write one, which requires more native code in the container.

2) Modify /etc/zprofile and fish's analog. There's no profile.d equivalent for zsh, so we'd have to set up a dpkg divert to overwrite /etc/zprofile with our own. If the user overwrites this file (which is fair game, it's under /etc), DISPLAY will be gone again.

3) Set DISPLAY when running /bin/login. This is the only surefire way to guarantee it's set, but requires querying the container first to check sommelier first. It also requires using -p to preserve env variables during login, but we'd have to clean up our env variables to prevent leaking from the host.

I'm leaning towards 3.

Note that this will be less of a problem when we enable the launcher and it can make sure DISPLAY is set correctly. I guess we still want terminals to have it set correctly when using a new login shell but maybe what we have today is good enough for that?

there is no end to the # of alternative shells out there.  it's impossible to try to support them all via their shell-specific setup scripts.  adding an exception for bash-compatible scripts (and perhaps even zsh) is fine, but that'd be the line to draw.  if the weird fish shell doesn't work out of the box, well that's just unfortunate.  it's not common enough for us to care imo, and fish users already grok that they need to deal with this sort of thing themselves.  just like tcsh and every other one out there.

of course, finding a way that's shell independent would be ideal.

The launcher code might be able to set DISPLAY and XCURSOR_SIZE instead of having that be done by a /etc/profile.d file.

It wouldn't work for when you ssh into the VM but I'm not sure how much we care about that use case now that we have a launcher. I'm not even sure that setting DISPLAY in that case is appropriate. If ssh X forwarding is enabled and you're connecting from a host that has a different X server, then you'd expect X clients to connect to that X server.

jkardatzke@, what do you think about moving this to the guest side launcher code? we basically want to do what the last two lines of /etc/profile.d/sommelier.sh does before we launching an app. There's c-code api to do the same if that's preferred in the launcher.

I'm tackling this with vsh, which will be shell-independent.

Fixed on  issue 819324 

Verified on 10798.0.0 with zsh