Change:
<ins> --- a/daemon/gdm-wayland-session.c +++ b/daemon/gdm-wayland-session.c @@ -285,6 +285,7 @@ spawn_session (State        *state, "WAYLAND_DISPLAY", "WAYLAND_SOCKET", "GNOME_SHELL_SESSION_MODE", +                                                    "__NIXOS_SET_ENVIRONMENT_DONE", NULL }; g_debug ("Running wayland session"); --- a/daemon/gdm-x-session.c +++ b/daemon/gdm-x-session.c @@ -610,6 +610,7 @@ spawn_session (State        *state, "WAYLAND_DISPLAY", "WAYLAND_SOCKET", "GNOME_SHELL_SESSION_MODE", +                                                     "__NIXOS_SET_ENVIRONMENT_DONE", NULL }; g_debug ("Running X session"); </ins>

Discussion:
My NixOS system has plenty of packages installed in . This used to work fine, i.e. the GNOME3 desktop always found those applications. After the recent switch to gdm, however, I regularly log in and all those applications have disappeared from the applications menu. At that point, the only thing that appears to help is to reboot the machine. Once the machine has restarted, all applications from that profile are visible again. I use a current version of @ .
I would say that has something to do with the way environment variables are set. I think I experience the same issue after restarting . cc who touched that code in
I don't see how could have broken something in such a non-deterministic way that reboots would help. That would be truly mysterious. But assuming it did, does reverting it help in a deterministic way?
I do not think the PR broke that, I encountered the issue when restarting DM long before it was merged. I would suspect GDM did not launch the profile script in some cases.
I've encountered this (or a variation at least). Logging out and then in will sometimes result in a gnome session with a bad PATH IIRC, this breaks any desktop files which depends on the Exec being in the path. I've never encountered it on first login, only after logging in on the console I think. I believe variables like XDGDATADIRS looked correct. I suspected it was a wayland issue, as I first saw the behavior after switching to my wayland branch. But I guess it only surfaced due to me logging in and out a lot. Tried to trigger it in a VM using console/ssh log in and this seems to do the trick: a VM with gdm and gnome a gnome session from gdm in with ssh as the same user as the gnome session out from the gnome session (this can take a while for some reason) in again from gdm This should result in a bad path variable. Looking up PATH in I'm getting this (XDGDATADIRS looks okay): Logging out of the gnome session and then killing the ssh connection seems to fix the issue again. It looks like the ssh login needs to be active while logging out to trigger the issue. So pretty strange.
I am getting exactly this issue, as I ssh login between my workstations a lot.

The only way to interract with the system after that is to use SSH or a tty, since one can't even launch a term emulator then.
OK, I think I've figured things out somewhat. Reverting does indeed fix the issue. Using lightdm also avoids it. The main ingredients: GDM imports a base environment for the user from systemd (ie. ) If an variable taken from systemd is already set in GDM's environment it won't take effect. Which is the case for PATH. Gnome sessions exports its environment to systemd ssh/console log in persists the systemd --user process So logging into a gnome session will populate the systemd user environment including . Logging out of the gnome session while the same user is logged in with eg. ssh won't clear the systemd environment. Launching a new session will then have a good environment, but GDM comes in and clobbers PATH making the bug manifest. I'd say the main problem here is GDM clobbering PATH.
Looks like there's an upstream bug already:
The easiest fix might be to patch gdm to reset when setting up the base environment for a new session. This has the benefit of redoing the environment in case the system have been rebuilt compared to eg. just fixing PATH. (I have a working patch for this). An alternative would be to run manually in , but that will just force us to patch when adding wayland support, so I don't quite see the point. Reworking is possible, but might get kinda ugly. It would probably require us to force a reset of the environment when setting up login shells. That was the direction I took when making the shell environment fix in the first place, but the whole thing got quite complicated resulting the simpler fix. Any preferences?