"environment.DISPLAY" config option seems ineffective as of late

Hey,

I’ve noticed that as of late, my config option for environment.DISPLAY doesn’t carry to my containers. Here’s the full output to show what I mean:

joonas@astraea ~ $ lxc config show my-test-container
architecture: x86_64
config:
  environment.DISPLAY: :0.0
  image.architecture: amd64
  image.description: Gentoo current amd64 (20210816_17:36)
  image.os: Gentoo
  image.release: current
  image.serial: "20210816_17:36"
  image.type: squashfs
  image.variant: default
 ...
...
...
devices:
  X0:
    path: /tmp/.X11-unix
    source: /tmp/.X11-unix
    type: disk
  binpkgdir:
    path: /var/cache/binpkgs
    source: /home/joonas/sde1/binpkg
    type: disk
  distfiles:
    path: /var/cache/distfiles/
    source: /var/cache/distfiles/
    type: disk
  mygpu:
    type: gpu
ephemeral: false
profiles:
- default
stateful: false
description: ""
joonas@astraea ~ $ echo $DISPLAY
:0.0
joonas@astraea ~ $ lxc start my-test-container
joonas@astraea ~ $ lxc exec my-test-container -- su --login
Last login: Fri Jan  7 17:49:08 -00 2022 on pts/1
my-test-container ~ # echo $DISPLAY

my-test-container ~ # env | grep -i display
my-test-container ~ # 
logout
joonas@astraea ~ $ lxc stop my-test-container
joonas@astraea ~ $ lxc info --show-log my-test-container
Name: my-test-container
Location: none
Remote: unix://
Architecture: x86_64
Created: 2021/08/17 19:30 EEST
Status: Stopped
Type: container
Profiles: default

Log:

lxc my-test-container 20220107175028.251 WARN     cgfsng - cgroups/cgfsng.c:fchowmodat:1254 - No such file or directory - Failed to fchownat(38, memory.oom.group, 65536, 0, AT_EMPTY_PATH | AT_SYMLINK_NOFOLLOW )
lxc my-test-container 20220107175040.592 WARN     attach - attach.c:get_attach_context:477 - No security context received
lxc my-test-container 20220107175216.953 WARN     cgfsng - cgroups/cgfsng.c:cgroup_tree_remove:483 - No such file or directory - Failed to destroy 10(lxc.payload.my-test-container)
lxc my-test-container 20220107175216.954 WARN     cgfsng - cgroups/cgfsng.c:cgroup_tree_remove:483 - No such file or directory - Failed to destroy 20(lxc.payload.my-test-container)

This used to work a little while back, but christmas was pretty hectic and I was a lot away from my PC so I can’t exactly pinpoint when this stopped working. My guess would be an update from lxd-4.0.7 to lxd-4.0.8, or some other recent update (lxc…?)

If I manually export DISPLAY=:0.0 inside a container when it’s running, it works and I can launch GUI apps.

Any pointers?

Can you check with just a normal lxc exec NAME bash session if the environment is present?

I wonder if it’s not your su call that’s stripping it.

Indeed it works with that. Historically I’ve chosen to do su --login because bash didn’t load all the environment values either. I guess it’s some updated that happened on the container image?

Also why does it work with bash, but not with su --login, wonders me now.

su --login most likely hit the PAM stack include the PAM module in charge of clearing the environment on login. su without --login may avoid that, as might sudo -E -u USER.

It looks like it’s about the container image update. In stable gentoo, su comes from a package shadow while in unstable gentoo, it comes from util-linux. Reading the manpages, even shadow’s su --login shouldn’t keep the environment variables and I’ve been using this all wrong :slight_smile:

Stable:

$ equery b /bin/su
 * Searching for /bin/su ...
sys-apps/shadow-4.9-r4 (/bin/su)

Unstable:

# equery b /bin/su
 * Searching for /bin/su ... 
sys-apps/util-linux-2.37.2-r3 (/bin/su)

To my delight just calling bash seems to work again (might’ve been shadow-related) so I’m going to switch back to it. Thanks!

EDIT: https://github.com/shadow-maint/shadow/releases/tag/v4.10 (I guess this is what you meant @stgraber with your previous post)