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


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
  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
    path: /tmp/.X11-unix
    source: /tmp/.X11-unix
    type: disk
    path: /var/cache/binpkgs
    source: /home/joonas/sde1/binpkg
    type: disk
    path: /var/cache/distfiles/
    source: /var/cache/distfiles/
    type: disk
    type: gpu
ephemeral: false
- default
stateful: false
description: ""
joonas@astraea ~ $ echo $DISPLAY
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 ~ # 
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


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:


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


# 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)