search

sodiboo / niri-flake

Nix packages and modules for niri
https://github.com/YaLTeR/niri
MIT License
72 stars 10 forks source link

Systemd integration is quite a mess... #348

Open e-tho opened 4 days ago

e-tho commented 4 days ago

The systemd integration is quite a mess compared to the Sway and Hyprland modules.

The swayidle service won't start because it doesn't have access to the WAYLAND_DISPLAY variable, and the wbg and waybar services work erratically when binded to graphical-session.target.

I've seen that in your personal configuration, some hacks had to be implemented to get around these problems, but this is far from desirable...

A solution using a session target would be much better integrated with NixOS/Home Manager, as most modules that need integration provide a systemdTarget parameter to set the relevant one. It can also be easily integrated into custom services.

I'm not sure whether these changes can be made directly in the NixOS module or whether they need to be made on the niri side, as the author seems to be leaning towards a different solution for systemd integration that uses a session script and no target.

sodiboo commented 4 days ago

For the systemd unit niri.service, I'm just using the exact file provided by upstream. To be honest, I'm not very knowledgeable in systemd, but you are right that my personal configuration relies on some hacks to get everything working smoothly. It's not all too awful at this point, though. I believe this flake (and my system, i guess) does it "as intended" by upstream, but that could definitely be improved on. I've also experienced waybar behaving erratically when binded to graphical-session.target and that's why my configuration does annoying things to bind it to niri.service instead,

@YaLTeR do you have any input on this? why it's done the way it is now, rather than something more similar to what everyone else seems to be doing? It would definitely be a lot nicer if we could rely on graphical-session.target to start services.

YaLTeR commented 4 days ago

Relying on graphical-session.target is the intended way and, well, it works on my machine (tm). This is what I describe here: https://github.com/YaLTeR/niri/wiki/Example-systemd-Setup

The only reason niri.service.wants is part of that, is to restrict those example services to only start in niri (and not if you log into GNOME for example). If things didn't work, they would start at exactly the same time as niri.service, which is indeed too early, but the graphical-session rules make them start at the correct time.

I'm not sure why it's not working on NixOS.

YaLTeR commented 4 days ago

To elaborate, this is the expected order of events:

  1. niri-session runs and starts niri.service
  2. niri.service ExecStart-s /usr/bin/niri --session, then waits for a notification (Type=notify)
  3. niri imports WAYLAND_DISPLAY and whatnot into the systemd environment:
  4. niri notifies systemd that it is ready: https://github.com/YaLTeR/niri/blob/7b6fa1285475896ad8dbc2f4b11099b0c036e4b7/src/main.rs#L224
  5. systemd now proceeds to start graphical-session.target (since niri.service says Before=graphical-session.target). At this point the environment is filled in and everything is ready
  6. systemd starts everything that has After=graphical-session.target, Requisite=graphical-session.target, i.e. example swaybg.service from the wiki page
e-tho commented 3 days ago

It seems to be a NixOS problem:

It's crazy that this has been around for so long. I'd already stumbled on the Wayland session wrapper issue because my services wouldn't start when I switched sessions via greetd when I was on Hyprland, but now with Niri this occurs right at startup. The services don't seem to start at the right time or lack the necessary context to run properly.