Enabling GNOME’s experimental realtime-scheduling unsets LD_LIBRARY_PATH

[royneary]

When I login to a Gnome+Wayland session LD_LIBRARY_PATH is always empty even though it should have been set in /etc/profile.

I came across this because I have an issue with SANE. My /etc/profile sets these two variables (by sourcing /nix/store/hh8...q2w-set-environment):

export LD_LIBRARY_PATH="/nix/store/kyyjfjx4i2vgldbxjn7z6nkr1dxb7c05-sane-config/lib/sane"
export SANE_CONFIG_DIR="/nix/store/kyyjfjx4i2vgldbxjn7z6nkr1dxb7c05-sane-config/etc/sane.d"

After logging in SANE_CONFIG_DIR is set correctly but LD_LIBRARY_PATH is empty. When I login to a Gnome+XServer session both variables are set as expected.

To Reproduce
Steps to reproduce the behavior:

1. Configure Gnome+Wayland and SANE

  hardware.sane = {
    enable = true;
    extraBackends = [ pkgs.epkowa ];
  };

  services.xserver = {
    enable = true;
    layout = "de";
  };

  services.xserver.displayManager.gdm = {
    enable = true;
    wayland = true;
  };
  services.xserver.desktopManager.gnome3.enable = true;

2. Login to a Gnome+Wayland session

3. check LD_LIBRARY_PATH

$ echo $LD_LIBRARY_PATH
$

Expected behavior
LD_LIBRARY_PATH should be set like in a GNOME+XServer session:

$ echo $LD_LIBRARY_PATH
/nix/store/kyyjfjx4i2vgldbxjn7z6nkr1dxb7c05-sane-config/lib/sane

Metadata

• system: "x86_64-linux"
• host os: Linux 5.4.45, NixOS, 20.03.2133.8946799e079 (Markhor)
• multi-user?: yes
• sandbox: yes
• version: nix-env (Nix) 2.3.6
• channels(root): "nixos-20.03.2133.8946799e079"
• nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos

Maintainer information:

# a list of nixpkgs attributes affected by the problem
attribute:
# a list of nixos modules affected by the problem
module:

[Cogitri]

GNOME Wayland doesn't use the environment variables defined in /etc/profile, because it isn't launched from a shell (like GNOME Xorg is). Environment variables for Wayland sessions should be defined in /usr/share/gdm/env.d/, see how Flatpak does this for an example:
https://github.com/flatpak/flatpak/blob/master/env.d/flatpak.env.in

[hedning]

It's worth trying to comment out these lines, that helped with [another problem] for some strange reason](#86730 (comment)) (follow these directions to build the system from a git repo:

nixpkgs/nixos/modules/services/x11/desktop-managers/gnome3.nix

Lines 299 to 310 in 83182f4

	systemd.user.services.gnome-shell-wayland = let
	gnomeShellRT = with pkgs.gnome3; pkgs.runCommand "gnome-shell-rt" {} ''
	mkdir -p $out/bin/
	cp ${gnome-shell}/bin/gnome-shell $out/bin
	sed -i "s@${gnome-shell}/bin/@${config.security.wrapperDir}/@" $out/bin/gnome-shell
	'';
	in {
	# Note we need to clear ExecStart before overriding it
	serviceConfig.ExecStart = ["" "${gnomeShellRT}/bin/gnome-shell"];
	# Do not use the default environment, it provides a broken PATH
	environment = mkForce {};
	};

@Cogitri while display managers doesn't setup the environment for the wayland sessions they launch, gnome-shell (through gnome-session) on wayland runs a login shell (using the user's $SHELL) on startup. On NixOS is the primary way the environment is setup on gnome wayland.

In that vein it's worth mentioning the login shell might do different things than the X11 setup (which mostly just sources /etc/profile). Eg. if you're a ZSH user on Wayland the setup will include ~/.zshrc etc.

[doronbehar]

GNOME Wayland doesn't use the environment variables defined in /etc/profile, because it isn't launched from a shell (like GNOME Xorg is)

@Cogitri while display managers doesn't setup the environment for the wayland sessions they launch, gnome-shell (through gnome-session) on wayland runs a login shell (using the user's $SHELL) on startup. On NixOS is the primary way the environment is setup on gnome wayland.

In that vein it's worth mentioning the login shell might do different things than the X11 setup (which mostly just sources /etc/profile). Eg. if you're a ZSH user on Wayland the setup will include ~/.zshrc etc.

Exactly. My observation is the same. It seems that only LD_LIBRARY_PATH is an exception - mostly every other variable from /etc/pamv.d/, /etc/set-environment, /etc/environment.d are set, except this one and perhaps TZDIR.

I've also spent a few hours debugging why simple-scan & xsane didn't detect my network scanner unless launched from a terminal / my previous machine that used Xorg. Almost opened a bug report upstream.

For clarity's sake, @hedning's suggestion for removing the override means applying this patch:

diff --git i/nixos/modules/services/x11/desktop-managers/gnome3.nix w/nixos/modules/services/x11/desktop-managers/gnome3.nix
index 69cf9832172..fe2489f5e16 100644
--- i/nixos/modules/services/x11/desktop-managers/gnome3.nix
+++ w/nixos/modules/services/x11/desktop-managers/gnome3.nix
@@ -296,15 +296,9 @@ in
         capabilities = "cap_sys_nice=ep";
       };
 
-      systemd.user.services.gnome-shell-wayland = let
-        gnomeShellRT = with pkgs.gnome3; pkgs.runCommand "gnome-shell-rt" {} ''
-          mkdir -p $out/bin/
-          cp ${gnome-shell}/bin/gnome-shell $out/bin
-          sed -i "s@${gnome-shell}/bin/@${config.security.wrapperDir}/@" $out/bin/gnome-shell
-        '';
-      in {
+      systemd.user.services.gnome-shell-wayland = {
         # Note we need to clear ExecStart before overriding it
-        serviceConfig.ExecStart = ["" "${gnomeShellRT}/bin/gnome-shell"];
+        serviceConfig.ExecStart = ["" "${pkgs.gnome3.gnome-shell}/bin/gnome-shell"];
         # Do not use the default environment, it provides a broken PATH
         environment = mkForce {};
       };

So, we don't open a PR because we don't know to explain what's wrong with the wrapper right? I have an undeveloped suspicion that it's due to the way our wrappers are created? Could it be that e.g LD_LIBRARY_PATH are not inherited by this executable?

In the meantime, @hedning could you explain a bit better the motive for 927a6fd ? I mean, why does it need RT scheduling?

[hedning]

Gnome shell, or rather mutter gained the ability to run with soft realtime scheduling, which in theory should improve performance. To get this to work we need a security wrapper which provides the necessary capability.

It's worth noting that it's not enough to launch with the capability, there's a gsettings switch which needs to be turned on too (mutter's experimental-features array needs to contain 'rt-scheduler').

So, we don't open a PR because we don't know to explain what's wrong with the wrapper right?

I've kinda forgot about the issue, but we should probably disable the wrapper for now since it breaks things (would be nice to get into 20.09). Regardless of our understanding the underlying issue, it's a fairly minor feature which probably aren't used by many people (especially since it's not enabled by default).

Might be nice having a preference for it, but it's not a big deal tbh.

Could it be that e.g LD_LIBRARY_PATH are not inherited by this executable?

Yeah, that sounds likely. If the patch you posted works that rules out the systemd service as the culprit, which pretty much leaves the security wrapper.

Edit: yeah, LD_LIBRARY_PATH is cleared when an application with extra capabilities: https://stackoverflow.com/questions/9843178/linux-capabilities-setcap-seems-to-disable-ld-library-path. Not sure if the same goes for TZDIR though, that doesn't really make sense.

[stale]

I marked this as stale due to inactivity. → More info

[doronbehar]

I'll only note that now the "conflict" in nixos between this option and configuring sane scanners, is documented thanks to https://github.com/NixOS/nixpkgs/pull/99697/files . Also, I think that sane and other scanning packages should get their environment altered in an override, and not as part of the whole system's environment. This would make this a non-issue, but still keep #86730 an issue relevant for the realtime-scheduling option.