nixos/hypridle: hypridle incorrectly starts on other DEs as it is wantedBy graphical-session.target

[Atemu]

Describe the bug

A clear and concise description of what the bug is.

Discovering this bug was quite a doozy. hypridle.service is not actually wanted by graphical-session.service because it's not linked in /etc/systemd/user/graphical-session.target.wants/.

Steps To Reproduce

Steps to reproduce the behavior:

1. programs.hypridle.enable
2. systemctl --user list-dependencies graphical-session.target

Expected behavior

A clear and concise description of what you expected to happen.

hypridle.service should be wanted by graphical-session.target

Screenshots

If applicable, add screenshots to help explain your problem.

Additional context

Add any other context about the problem here.

The upstream intention appears to be that hypridle starts with graphical-session.target. This, however, is only useful if you want all of your sessions to have hypridle running which is likely not the case if you have any desktop session other than hyprland.

I personally solve this by introducing a hypr-session.target which wants graphical-session.target (you need something like this in order to even be able to start graphical-session.target anyways) but that requires me to configure hyprland to start and stop this target.

Honestly at this point, I think the hypridle option should simply be removed. Enabling hypridle is not something NixOS can reasonably handle for the user at this moment.

Perhaps we can get upstream to make such a hypr-session.target an official thing and add logic to the compositor to handle it so that the target works without any hyprland user config similar to the systemd env vars integration.

Notify maintainers

@fufexan @JohnRTitor @wozeparrot

Metadata

Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.

[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
output here

---

Add a 👍 reaction to issues you find important.

[JohnRTitor]

Looks like the same issue as #340874 (comment)

We just need to specify it manually like this:

nixpkgs/nixos/modules/programs/wayland/waybar.nix

Line 25 in c31898a

user.services.waybar.wantedBy = [ "graphical-session.target" ];

[Atemu]

That would indeed be the "fix" but please read the discussion in "additional context".

[JohnRTitor]

Perhaps we can get upstream to make such a hypr-session.target an official thing and add logic to the compositor to handle it so that the target works without any hyprland user config similar to the systemd env vars integration.

That would be a decision of @fufexan and Vaxry.

I think the hypridle option should simply be removed.

The NixOS option is pretty basic way of installing the package and enabling the service. Of course any customisation should be done via .config file by users.

Enabling hypridle is not something NixOS can reasonably handle for the user at this moment.

Nor other distros. A service depending on graphical-session will always be run in every DE that start the target.

Perhaps you might consider running the other DEs in specialisation so that they never conflict with each other.

[Atemu]

I'd appreciate if you didn't just merge a band-aid while we're still in the middle discussing the core of the issue.

[Atemu]

The NixOS option is pretty basic way of installing the package and enabling the service

That's the thing though: If enabling the service isn't something we can reasonably do from the NixOS side, all the module would do is add hypridle to systemPackages and we don't need a module for that; the user could just do that themselves.

Nor other distros. A service depending on graphical-session will always be run in every DE that start the target.

That's honestly just broken. I don't think we should ship/enable such a broken system in NixOS.

Users can decide to use it using simple tools but that's on them in that case.

[JohnRTitor]

Thanks for reopening this, didn't mean to close the discussion, forgot to unlink the issue before merging.

The PR was a valid fix so I did not think it would be right to stall it.

[Atemu]

The PR was a valid fix so I did not think it would be right to stall it.

My argument is that it's not a "valid fix". It adds a band-aid to enable a system that is fundamentally broken.

Perhaps you might consider running the other DEs in specialisation so that they never conflict with each other.

Forgot to reply to this:

Specialisations are never a good solution, especially to problems like this one that need to be handled dynamically.

[JohnRTitor]

That's the thing though: If enabling the service isn't something we can reasonably do from the NixOS side

The safest way of doing it would be from a distro-side Hyprland config file as mentioned in #335625 (comment)

exec-once = hypridle &

[JohnRTitor]

While we are waiting for that to be implemented, if this really needs to be dynamic right now, hypridle could just be added to systemPackages and then started from hyprland user config file instead.

[Atemu]

exec-once = hypridle &

This is in no way equivalent to a systemd service.

if this really needs to be dynamic right now,

I don't see any need for haste here.

[JohnRTitor]

My argument is that it's not a "valid fix". It adds a band-aid to enable a system that is fundamentally broken.

Issue title is that it didn't start with graphical-session, that part is fixed. I am not sure what else you want me to do here.

If a gnome service only wanted by graphical-session, it will be started even if a KDE session is running. Correct me if I am wrong, but I don't think we, as a distro, do not have a solution for this.

Running multiple DEs on a system will at some point cause a conflict. ie. GTK theme configured by KDE, will be applicable in GNOME as well because they modify the same config file.

Specialisations can isolate some part of it but that's it.

If a hypland-session.target is needed to better configure these type of services, that request should go to upstream, not here.

[fufexan]

Thoughts about the existing https://github.com/hyprwm/Hyprland/blob/main/example/hyprland-session.service? I was planning on configuring it through meson/cmake.

Perhaps we can get upstream to make such a hypr-session.target an official thing and add logic to the compositor to handle it so that the target works without any hyprland user config similar to the systemd env vars integration.

Will look into this.

[Atemu]

If a gnome service only wanted by graphical-session, it will be started even if a KDE session is running.

Indeed which is why GNOME has [email protected] AFAIUI.

Making this a template target (didn't even know that was possible) strikes me as a good design too.

If a hypland-session.target is needed to better configure these type of services, that request should go to upstream, not here.

Right the problem is that we as NixOS chose to provide a hypridle user service that is fundamentally broken, that's the issue at hand here.

Thoughts about the existing https://github.com/hyprwm/Hyprland/blob/main/example/hyprland-session.service? I was planning on configuring it through meson/cmake.

Hm, not sure whether we should have the whole compositor in a service. This would require integration from the login managers right?

The target should exist independently of that though. The interesting part is that Hyprland would need to internally start and stop this target based on its internal state (start it after startup, stop it before shutdown).

Running it as a service could automatically start and stop the target but that seems most useful as a fallback to stop the session target when hyprland crashes. Not sure how other DEs handle this.

[Atemu]

GNOME appears to have a session-manager service which is somehow started by gnome-session-binary.

KDE has a plasmashell.service and a plasma-kwin_wayland.service which are somehow started by startplasma-wayland.

So it appears running the compositor as a systemd service isn't far fetched.

[Atemu]

The decision was reached upstream to recommend using https://github.com/Vladimir-csp/uwsm/ as the "official" method to launch Hyprland as a systemd unit.

I think we should integrate that into our hyprland NixOS module and make hypridle use the target generated by uwsm.

What do you think about having a programs.hyprland.uwsm.enable which automatically creates a uwsm waylandCompositor for Hyprland and then making hypridle's systemd service depend on those targets when config.programs.hyprland.uwsm.enable?

[fufexan]

I'm all for it. Though I'm unsure of the route we should take to make hypridle depend on the Hyprland session:

1. We simply add .wantedBy = "wayland-session@hyprland\x2duwsm.desktop.target";
2. We add .serviceConfig.ExecCondition = ''${pkgs.systemd}/lib/systemd/systemd-xdg-activation-condition "Hyprland" ""'';

Option 1 would allow users to add other targets as well (to run hypridle with other compositors), while option 2 would limit hypridle's use to Hyprland only.

[Atemu]

I don't know how systemd-xdg-activation-condition is supposed to be used but it doesn't smell nice at first smell IMHO. If we can, we should declare proper dependencies on the correct targets. If users want it to be used in other targets too, they need to explicitly declare that.

As for declaring the dependency relation:

1. Hyperidle should be started with the hyprland session
2. Only after the compositor is up
3. The graphical session should only be considered up once hypridle is up (or has failed to start)
4. Hypridle should stop when the session is brought down

That should mean:

{
  wantedBy = [ "[email protected]" ];
  after = [ "[email protected]" ];
  before = [ "[email protected]" ]; # or graphical-session.target?
  partOf = [ "[email protected]" ];
}

right?

cc @Vladimir-csp on guidance on how the uwsm's units are supposed to be used in cases like this.

[Atemu]

What I just posted appears to be working correctly for me, though race conditions are always hard to notice of course. I'll run with this for a bit.

[Vladimir-csp]

I don't know how systemd-xdg-activation-condition is supposed to be used but it doesn't smell nice at first smell IMHO.

ExecCondition=/lib/systemd/systemd-xdg-autostart-condition "Hyprland" ""

It takes two arguments: contents of OnlyShowIn and NotShowIn. It's Desktop Entry autostart logic. This is how I run swayidle.

2. Only after the compositor is up
3. The graphical session should only be considered up once hypridle is up (or has failed to start)

A tricky condition. Might try to squeeze it between generic and specific target if that won't cause a loop.

[Unit]
...
# deactivate with session
PartOf=graphical-session.target
# ordering
Before=graphical-session.target
[email protected] [email protected]
...
[Service]
...
# low priorities
Slice=background-graphical.slice
...
[Install]
[email protected] [email protected]

[Atemu]

It takes two arguments: contents of OnlyShowIn and NotShowIn. It's Desktop Entry autostart logic. This is how I run swayidle.

Ah this is the same weird syntax that portals also use to limit in which desktops they run.

Yeah I think I'd prefer us to use proper systemd dependencies to implement this. Users could opt to use this if they wish though.

# deactivate with session
PartOf=graphical-session.target
# ordering
Before=graphical-session.target
[email protected] [email protected]

Interesting, is there a specific reason to prefer graphical-session over the wayland-session@ for these? I would have thought it'd be more fitting to have it be part of the hyprland-specific session.

Same question for After=wayland-session@: is there a reason for that or would Before also work; making the wayland-session@ target the point at which the hyprland-session would be considered up?

low priorities

Slice=background-graphical.slice

Ooh, this is a thing?

Do you have documentation how this works/what this does? I wasn't able to find it in the readme.

I'm not sure we want to de-prio hypridle though as it is responsible for starting the screen lock which should happen promptly.

[Vladimir-csp]

Ah this is the same weird syntax that portals also use to limit in which desktops they run.

Nothing weird

is there a specific reason to prefer graphical-session over the wayland-session@ for these?

Compactness, PartOf just propagates stop and restart actions.

Same question for After=wayland-session@: is there a reason for that or would Before also work; making the wayland-session@ target the point at which the hyprland-session would be considered up?

The order is:

1. [email protected], wayland-session-waitenv.service
2. [email protected]
3. graphical-session.target.

hypridle needs WAYLAND_DISPLAY. Usually this is guaranteed by After=graphical-session.target, but since you want it before that, there needs to be another After that is still ordered after compositor's unit. It's either compositor's unit itself, or an intermediary target.

[Vladimir-csp]

Ooh, this is a thing?
Do you have documentation how this works/what this does? I wasn't able to find it in the readme.

man systemd.special.

background.slice is canonical, background-graphical.slice is uwsm-specific (nested in background.slice because of name, dashes have special meaning), it also receives deactivation actions.

It's totally optional.

[Atemu]

hypridle needs WAYLAND_DISPLAY. Usually this is guaranteed by After=graphical-session.target, but since you want it before that, there needs to be another After that is still ordered after compositor's unit. It's either compositor's unit itself, or an intermediary target.

That was what I intended to do using after = [ "[email protected]" ];. That should work, right?

I should probably also make it a Requisite= though.

background.slice is canonical, background-graphical.slice is uwsm-specific (nested in background.slice because of name, dashes have special meaning), it also receives deactivation actions.

I see, thanks.

The systemd documentation on this is a bit ...sparse. What does it actually do in terms of cgroup settings?
It's unrelated to this but I've been wanting to effectively curb a background process (compilation) so that it cannot cause latency spikes for any other process but CPUSchedulingPolicy of batch or idle seemingly didn't help with "foreground" latency at all, only throughput.

[Atemu]

hypridle needs WAYLAND_DISPLAY. Usually this is guaranteed by After=graphical-session.target, but since you want it before that, there needs to be another After that is still ordered after compositor's unit. It's either compositor's unit itself, or an intermediary target.

Isn't this precisely what you made [email protected] for? Can't I just make the unit After this?

---

I tried changing the name of the compositor using our NixOS module but I was quite confused to find out that lower-casing it doesn't work; uwsm always generates it uppercase. How does the compositor name generation for unit names work? Does it just take the binary's name?

[Vladimir-csp]

How does the compositor name generation for unit names work? Does it just take the binary's name?

Binary name or Desktop Entry ID, whichever you run uwsm start with.

[Vladimir-csp]

Isn't this precisely what you made [email protected] for? Can't I just make the unit After this?

[email protected] was made to find and launch any compositor by name or ID provided in the specifier.

Configuring ordering on its specific instance will work, no problem here. It's just not something people usually do.

[JohnRTitor]

The decision was reached upstream to recommend using https://github.com/Vladimir-csp/uwsm/ as the "official" method to launch Hyprland as a systemd unit.

Perhaps, we should be providing a withUWSM option for the hyprland module then? It would replace the vanilla wayland-sessions/hyprland.desktop file, such that DMs will use UWSM when starting Hyprland. This can have benefits like initializing proper targets like graphical-session.target.

[fufexan]

We're going to also provide a hyprland-uwsm.desktop file upstream, not sure if we should also configure uwsm.waylandCompositors.hyprland in that case.

See hyprwm/Hyprland#8376.

[Atemu]

[email protected] was made to find and launch any compositor by name or ID provided in the specifier.

Sorry, I don't follow. Could you elaborate?

(I meant [email protected] btw, I know how the systemd templating works.)

[Vladimir-csp]

Sorry, I don't follow. Could you elaborate?

(I meant [email protected] btw, I know how the systemd templating works.)

Sorry, I didn't notice -env part in the question and just copypasted. [email protected] sets session variables (XDG_CURRENT_DESKTOP, etc), loads shell profile, plugins, additional env files, and manages loading environment delta into systemd and preparations for subsequent cleanup. All this is part of graphical-session-pre.target and happens before compositor is started, so there is no WAYLAND_DISPLAY at this point.

[Atemu]

Got it, we do want to depend on the wm service then.

I've been running with these constraints on two machines, one with two hypridle instances and it's working mighty fine so far. It's really blissful when things just work like that; really impressed with uwsm's function so far.

Binary name or Desktop Entry ID, whichever you run uwsm start with.

Slightly OT but what is this "Desktop Entry ID"? That's not a field I could find in the specification.

Basically, we're doing this right now:

nixpkgs/nixos/modules/programs/wayland/uwsm.nix

Lines 16 to 20 in 5812399

	[Desktop Entry]
	Name=${opts.prettyName} (UWSM)
	Comment=${opts.comment}
	Exec=${lib.getExe cfg.package} start -S -F ${opts.binPath}
	Type=Application

Which explicitly starts the binary via uwsm CLI. How would we do it using the desktop entry id instead?

[fufexan]

@Atemu Desktop Entry ID is the .desktop file itself. uwsm will search through all the sessions to find the one provided. A full path can also be passed.

This is also the case for uwsm app, which I've adapted an anyrun plugin for.

[Vladimir-csp]

Desktop Entry ID is the .desktop file itself. uwsm will search through all the sessions to find the one provided. A full path can also be passed.

Basename of the file, but not exactly. In case of applications it can be different from basename if entry file is located in a subdir. But no such rule seem to exist explicitly for wayland-sessions, and I doubt it will ever come to subdirs there. ...famous last words.

[fufexan]

I've merged the uwsm session file and the wiki instructions in Hyprland. Now we can work on adding it to the Hyprland module.

I've intentionally left out the -uwsm session file when building on Nix, as it does not have full paths and therefore uwsm cannot find the required binaries. We'll use programs.uwsm.waylandCompositors instead.

[JohnRTitor]

We'll use programs.uwsm.waylandCompositors instead.

Would be nice getting a option for this inside programs.hyprland. PRs welcomed.

[Vladimir-csp]

launching Desktop Entry is "prettier" compared to binary, because Name and Comment keys are used to fill Description attribute of units. Otherwise, and unless Entry's Exec contains some custom args, there is no difference

[Atemu]

Our current uwsm module implementation isn't great in this regard and we should fix that. That's for a separate issue though.

Question for @fufexan and @JohnRTitor do we want to support non-uwsm launch in our hyprland and hypridle modules?

I was thinking to allow it for Hyprland for those who don't want to commit to a fully systemd-managed setup but require it for the hypridle service because it cannot be implemented sensibly without. My reasoning is that if you don't want systemd user units for everything, you'd just launch hypridle from your hyprland start or something anyways.

[JohnRTitor]

launching Desktop Entry

So, desktop entry by path supported now? Last time we had this conversation, we didn't.

Our current uwsm module implementation isn't great in this regard and we should fix that

There's definitely a room for improvement. Pretty much did a barebones implementation based on what was available at that time

Question for @fufexan and @JohnRTitor do we want to support non-uwsm launch in our hyprland and hypridle modules?

I was thinking of an one click toggle programs.hyprland.withUWSM (disabled by default, for now) to atleast configure the Hyprland with UWSM session. This would replace the original Hyprland.desktop file. Of course, Hyprland could still be launched standalone via a TTY.

[Atemu]

Yeah I think the same.

I'm most concerned with the hypridle module though which this issue ostensibly is about.

[JohnRTitor]

    systemd.user.services.hypridle.wantedBy = [ (if config.programs.hyprland.withUWSM then "[email protected]" else "graphical-session.target") ];

This should fix the issue if UWSM is used. We can enable withUWSM by default after the branch off.

[JohnRTitor]

By the way, if Hyprland is used with UWSM, it seems to leak python3 into the environment? Does this happen for you all?

If yes, we may need to fix our packaging.

[Atemu]

This should fix the issue if UWSM is used.

I know. What I wanted to discuss is whether we should retain the (IMHO) broken alternative of depending on graphical session.

[JohnRTitor]

I would be in favor of keeping it.

Another implementation I could think of is checking for something Hyprland specific, like a directory/file that only exists when Hyprland session is running for instance.

What I am doing with sched-ext for example: https://github.com/NixOS/nixpkgs/pull/352300/files#diff-999da5c78431b99032ddb89d748beb2fcce2d46ea5a95fb5195cdec042dde310R86

  systemd.user.services.hypridle.unitConfig.ConditionPathIsDirectory = "/run/user/1000/hypr";

/run/user/1000/hypr afaik this directory only exists during a Hyprland session.

EDIT:
According to https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html, we should be using %U to get the UID for the user.

So a proper solution would be:

  systemd.user.services.hypridle.unitConfig.ConditionPathIsDirectory = "/run/user/%U/hypr";

[JohnRTitor]

Seems to work. PR incoming.