TZDIR not set in gnome3 session

[danderson]

Describe the bug

I'm on NixOS 20.03. The displayed time in my Gnome on Wayland session was wrong, both in the GUI bar and in all terminals launched within the session:

> date
Mon 04 May 2020 06:45:02 AM America

Compare to in a TTY login session:

> date
Sun 03 May 2020 11:45:23 PM PDT

Thanks to @multun and friends on #nixos, we tracked it down to my gnome session having the TZ envvar set, but not TZDATA:

> printenv | grep TZ
TZ=America/Los_Angeles

vs. in a TTY session:

> printenv | grep TZ
TZDIR=/etc/zoneinfo
TZ=America/Los_Angeles

With only TZ set, glibc ignores /etc/localtime and tries to load timezone data from the glibc store path. This fails because the glibc derivation doesn't include timezone data:

openat(AT_FDCWD, "/nix/store/6m2k8kx8h216jlx9dg3lp4m90bz05yck-glibc-2.30/share/zoneinfo/America/Los_Angeles", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

Compare to where /etc/zoneinfo points to: /nix/store/0mpmbpxhads74gchcs5nwxsl2im66g9a-tzdata-2019c/share/zoneinfo

TZDATA is normally set through /etc/set-environment, invoked by /etc/profile. The displayed time is correct in GDM, and only becomes incorrect when the gnome session itself starts. So, either session startup isn't populating the environment correctly, or gnome is clearing TZDATA on startup somehow.

Note that this only manifests if you set TZ explicitly in your env, like I do in my shell configuration (I set it to get consistent time display on machines I ssh into). If TZ is unset, glibc defaults to /etc/localtime, which results in correct behavior. The weirdness in Gnome only triggers because I explicitly set TZ, and TZDATA is not set.

This bug is related to #65415 . In that bug the request was to burn a correct default for TZDATA into glibc, to avoid reliance on the TZDATA envvar. I've just discovered a weird way to trigger the bad behavior :).

To Reproduce

1. Install Gnome on Wayland
2. Log in
3. Open a terminal
4. export TZ=America/Los_Angeles
5. date shows UTC time with the bogus "America" timezone.

Expected behavior

Gnome should keep TZDATA set in the session, to be consistent with the rest of NixOS.

cc @jtojnar and @worldofpeace, resident Gnome experts according to IRC.

Metadata

 - system: `"x86_64-linux"`
 - host os: `Linux 5.4.35, NixOS, 20.03.1619.ab3adfe1c76 (Markhor)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.3.4`
 - channels(root): `"nixos-20.03.1619.ab3adfe1c76, nixos-hardware"`
 - channels(dave): `"home-manager"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

[alesya-h]

This also leads to the incorrect time being displayed in World Clocks section in the notification panel of the Gnome Shell:

I originally filed the issue upstream, but after debugging it I found that it's NixOS-specific and boils down to the following lines we have:

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

Lines 308 to 309 in af5accf

	# Do not use the default environment, it provides a broken PATH
	environment = mkForce {};

I believe we should find a better way to handle PATH than erasing the whole environment.

[jtojnar]

If I comment out the line, I see

$ nixos-option -I nixpkgs=$HOME/Projects/nixpkgs -I nixos-config=$HOME/Projects/nixfiles/hosts/kaiser/configuration.nix systemd.user.services.gnome-shell-wayland.environment
Value:
{ PATH = "/nix/store/66hc282zl28zfr8727i681vz23bqwp16-coreutils-8.31/bin:/nix/store/p8s52vp09jb4656w7ky8ihyfs45zrzpd-findutils-4.7.0/bin:/nix/store/sb3jw7cl7x08lmbwypnvlg75mfwh175h-gnugrep-3.4/bin:/nix/store/107xlqzpnr6zqi0kpw94lia5sf78z9i8-gnused-4.8/bin:/nix/store/zzr1p57r1ii6y0gm7kycid0gkw1hskp3-systemd-245.6/bin:/nix/store/66hc282zl28zfr8727i681vz23bqwp16-coreutils-8.31/sbin:/nix/store/p8s52vp09jb4656w7ky8ihyfs45zrzpd-findutils-4.7.0/sbin:/nix/store/sb3jw7cl7x08lmbwypnvlg75mfwh175h-gnugrep-3.4/sbin:/nix/store/107xlqzpnr6zqi0kpw94lia5sf78z9i8-gnused-4.8/sbin:/nix/store/zzr1p57r1ii6y0gm7kycid0gkw1hskp3-systemd-245.6/sbin"; }

@hedning do you remember what that was about?

Though TZDIR seems to be in the environment in either case:

[...]

# /nix/store/m15bnbj4bgby6s2crv7s60h9y7pzj5df-user-units/gnome-shell-wayland.service.d/overrides.conf
[Unit]

[Service]
Environment="LOCALE_ARCHIVE=/nix/store/1c7nfqq4l7w24y66d9dyqhldxprpfaac-glibc-locales-2.30/lib/locale/locale-archive"
Environment="TZDIR=/nix/store/2xf7xzc84pkn1g9fz3fdjq42pa5305qk-tzdata-2019c/share/zoneinfo"



ExecStart=
ExecStart=/nix/store/sibkmga5zlg749y1b9vinmbc626cdw57-gnome-shell-rt/bin/gnome-shell

$ systemctl cat --user gnome-shell-wayland
[...]

# /nix/store/bxvsgb2xqpg8nq1hcaf64kqwin6lc2yj-user-units/gnome-shell-wayland.service.d/overrides.conf
[Unit]

[Service]
Environment="LOCALE_ARCHIVE=/nix/store/1c7nfqq4l7w24y66d9dyqhldxprpfaac-glibc-locales-2.30/lib/locale/locale-archive"
Environment="PATH=/nix/store/66hc282zl28zfr8727i681vz23bqwp16-coreutils-8.31/bin:/nix/store/p8s52vp09jb4656w7ky8ihyfs45zrzpd-findutils-4.7.0/bin:/nix/store/sb3jw7cl7x08lmbwypnvlg75mfwh175h-gnugrep-3.4/bin:/nix/store/107xlqzpnr6zqi0kpw94lia5sf78z9i8-gnused-4.8/bin:/nix/store/zzr1p57r1ii6y0gm7kycid0gkw1hskp3-systemd-245.6/bin:/nix/store/66hc282zl28zfr8727i681vz23bqwp16-coreutils-8.31/sbin:/nix/store/p8s52vp09jb4656w7ky8ihyfs45zrzpd-findutils-4.7.0/sbin:/nix/store/sb3jw7cl7x08lmbwypnvlg75mfwh175h-gnugrep-3.4/sbin:/nix/store/107xlqzpnr6zqi0kpw94lia5sf78z9i8-gnused-4.8/sbin:/nix/store/zzr1p57r1ii6y0gm7kycid0gkw1hskp3-systemd-245.6/sbin"
Environment="TZDIR=/nix/store/2xf7xzc84pkn1g9fz3fdjq42pa5305qk-tzdata-2019c/share/zoneinfo"



ExecStart=
ExecStart=/nix/store/sibkmga5zlg749y1b9vinmbc626cdw57-gnome-shell-rt/bin/gnome-shell

[hedning]

To make sure the problem comes from the gnome-session-wayland.service override I'd comment the whole thing out and see if the problem persists (it's only used to launch with extra capabilites).

do you remember what that was about?

When building systemd services NixOS defaults to a very minimal PATH which isn't meant for user services. So IIRC instead of inheriting the path from the systemd user environment (which user services usually do) the service would reset the PATH to something broken.

I might be mistaken, but I'm fairly certain not having environment = mkForce {}; will leave you with a broken system.

Though TZDIR seems to be in the environment in either case:

Yeah, looks like that's added globally to all systemd services NixOS makes; https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/system/boot/systemd.nix#L333. I don't see how that could cause any trouble tbh.

Now wayland and X11 handles environment setup somewhat differently. On wayland it's done through a login shell (https://gitlab.gnome.org/GNOME/gnome-session/-/blob/master/gnome-session/gnome-session.in) while on X11 it's done through a shared wrapper: https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/services/x11/display-managers/default.nix#L31-L107.

I'm fairly certain I've seen some differences in the local/time handling between Wayland and X11 long before we implemented the real time wrapper, so my guess is the problem comes from the difference in how Wayland and X11 sets up the environment.

[alesya-h]

There's one more bug about environment and gnome+wayland: #90201 .

And regarding environment setup differences between X11 and Wayland, TZDIR is available in the Sway session. What is the difference between wayland gnome-shell and sway in regard to how the session is started?

[hedning]

Right, tested with and without the service override and it looks like the service override is indeed the problem in some way (environment = mkForce {} isn't the problem though, removing that still leaves you without TZDIR).

It's pretty strange though. Looking at /proc/${pidof gnome-shell}/environ it does indeed lack TZDIR, but correctly have the full LOCALE_ARCHIVE from the service override (ie. full path, no symlink). No idea what makes TZDIR special here tbh?

systemctl --user show-environment have the correct environment (ie. TZDIR=/etc/zoneinfo/) exported by gnome-session before launching gnome-shell.

Not sure what's going on here tbh, but since the service override isn't a necessity I guess we should disable it for now.

What is the difference between wayland gnome-shell and sway in regard to how the session is started?

On wayland the session is responsible for setting up the environment, gnome-shell does that through gnome-session (running a login shell with the users preferred shell and exporting the result to the systemd --user process), while sway will probably do it in some other way.

[worldofpeace]

I just had to fix this issue since the variable is called TZDIR.
I just checked in my session and

printenv TZDIR 
/etc/zoneinfo

and I have the experimental feature on the wayland session.

I'm also considering, maybe it just isn't working and that's why I can't reproduce it?
Does anyone remember how to check the capabilities?

[callahad]

@worldofpeace How are you launching your terminal? I've found that terminals launched via a keyboard shortcut inherit from the systemd user service, and thus gain the appropriate environment variables. Launching via Gnome's application launcher inherits from gnome-shell, which does not have the envvar.

See #99221 (comment)

[worldofpeace]

@worldofpeace How are you launching your terminal? I've found that terminals launched via a keyboard shortcut inherit from the systemd user service, and thus gain the appropriate environment variables. Launching via Gnome's application launcher inherits from gnome-shell, which does not have the envvar.

See #99221 (comment)

Interesting. My terminal is tilix and it was launched from gnome-shell. So I didn't do it via a shortcut.
I just not tested this in xterm and I can now reproduce. I wonder why the wrapped application has TZDIR but xterm didn't?

[stale]

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

[alesya-h]

Time seems to be displaying correctly for me now in nixos-unstable. @danderson do you still have the issue?