bug: opensnitch-ui starting too early makes xdg-desktop-portal-gnome fail to start after logging into GNOME

[nbCloud91]

Are you following the right branch?

• [X] My Nixpkgs and Home Manager versions are in sync

Is there an existing issue for this?

• [X] I have searched the existing issues

Issue description

opensnitch-ui service starting too early makes xdg-desktop-portal-gnome fail to start after logging into gnome. This issue is similar to the one caused by early Nextcloud service as reported here https://github.com/NixOS/nixpkgs/issues/206630

Relevant portion from the dump of journalctl --user -b:

Jan 28 11:38:40 nixos .xdg-desktop-po[1795]: cannot open display: 
Jan 28 11:38:40 nixos systemd[1565]: xdg-desktop-portal-gnome.service: Main process exited, code=exited, status=1/FAILURE
Jan 28 11:38:40 nixos systemd[1565]: xdg-desktop-portal-gnome.service: Failed with result 'exit-code'.
Jan 28 11:38:40 nixos systemd[1565]: Failed to start Portal service (GNOME implementation).
Jan 28 11:38:41 nixos systemd-coredump[1783]: [🡕] Process 1705 (.opensnitch-ui-) of user 1000 dumped core.

Maintainer CC

@onny

System information

- system: `"x86_64-linux"`
 - host os: `Linux 5.15.89, NixOS, 23.05 (Stoat), 23.05pre447289.9b97ad7b433`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.12.0`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

[berbiche]

Hi,

I believe the "start too early" bug you are referring to is a NixOS bug (IMO).

https://github.com/NixOS/nixpkgs/blob/33867e8d862dbbe1ea2db5ca04dbe630c957db86/nixos/modules/services/x11/display-managers/default.nix#L91-L104 NixOS' session scripts starts the user graphical session even before starting the desktop enviroment. It's likely that when the graphical-session.target is started, the variables $XDG_SESSION_TYPE, $XDG_CURRENT_DESKTOP and $XDG_SESSION_DESKTOP are unset.

[cscutcher]

I was having a similar issue, but in my case, rather than being a timing issue, it was a case of missing variables in the systemd user environment. For me the symptom was;

    Apr 22 16:45:29 aeryn xdg-desktop-portal-gnome[695413]: Failed to initialize display server connection: Unsupported or missing session type ''
    Apr 22 16:45:29 aeryn systemd[4399]: xdg-desktop-portal-gnome.service: Main process exited, code=exited, status=1/FAILURE
    Apr 22 16:45:29 aeryn systemd[4399]: xdg-desktop-portal-gnome.service: Failed with result 'exit-code'.
    Apr 22 16:45:29 aeryn systemd[4399]: Failed to start Portal service (GNOME implementation).

when starting a number of applications. For me, those applications did eventually start, I assume after some timeout expires, but the delay was considerable.

I seem to have resolved my issue by including extra variables via;

services.xserver.displayManager.importedVariables = [
    "XDG_SESSION_TYPE"
    "XDG_CURRENT_DESKTOP"
    "XDG_SESSION_DESKTOP"
];

Note, it's possible to confirm the variables able to systemd user units with;

systemctl --user show-environment

This works for me, as of nixpkgs 89d59988a72a14e190280ef7f33c2c749bad37b0 with nixos and home-manager as a nixos module, with none+i3 as my defaultSession.

[stale[bot]]

Thank you for your contribution! I marked this issue as stale due to inactivity. Please be considerate of people watching this issue and receiving notifications before commenting 'I have this issue too'. We welcome additional information that will help resolve this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

* If this is resolved, please consider closing it so that the maintainers know not to focus on this. * If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

* If you are also experiencing this issue, please add details of your situation to help with the debugging process. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

Don't be afraid to manually close an issue, even if it holds valuable information. Closed issues stay in the system for people to search, read, cross-reference, or even reopen – nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.