-
-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
systemd: add targets #8339
systemd: add targets #8339
Conversation
Anything that brings up Hyprland session on par to GNOME, KDE and other DE's will be a good addition. |
Also, might be related #8311 |
UPD: Okay, I wasn't able to install targets with both CMake and meson. There's just hyprland-session.service. |
Can you check the build directory? |
There is only hyprland-session.service under Hyprland/build/systemd if that's what you mean |
Hmm. Session file is installed from CMAKE_SOURCE_DIR, but target files are installed from CMAKE_BINARY_DIR. Maybe this is the problem? I'll replace CMAKE_BINARY with CMAKE_SOURCE and try again |
Sure, that could work. Cmake needs reworking anyway. |
Okay, nothing really changed for me, so far. The one problem I think I should mention - after exiting the compositor (hyprctl dispatch exit), and re-entering the session - there's a chance other user services won't start, namely - hyprpaper, hypridle, portal-hyprland., hyprpolkitagent. This isn't really a regression, because it happens with just hyprland-session.service in the main branch, but anyway. To reproduce - exit Hyprland session and re-enter again, several times, with and without binding graphical session to user login (i.e regardless of whether exiting the session should log a user out). UPD: Despite being 'broken', systemctl reports that the services are active and running. Also, when this happens - xcursor is broken, as well - it fallbacks to default adwaita 32 UPD 2: My guess is where watchdog process comes in. It should stop all services, that depend on the graphical session, before the session, itself, exited, so the services could be restarted upon re-entering the graphical session. And, if xcursor is being managed by something like dconf service, it explains why it breaks, too. |
Also, for some reason - meson doesn't autodetect systemd |
I think we don't even need a watchdog. We can use systemd's |
Meson should detect systemd as long as the option is enabled. It should probably be manually enabled. |
The problem is that units don't fail. They are just absent upon restart the session, but systemd reports they are active |
Then OnFailure and OnSuccess should have the same thing bound to them. So that units get stopped regardless of exit code. |
So currently it's like this, from my understanding
Theoretically hyprland being closed/crashing should stop both targets. You're saying this does not happen. I will have to dig deeper. |
If I understand this correctly, we could edit hypr* related units to have these conditions, but e.g. waybar.service has neither OnFailure nor OnSucces conditions. Something tells me, it has to be implemented the hard (GNOME/KDE) way. I didn't mention waybar and mpd-notification services earlier, because I have |
It does not matter, systemd should just kill the processes regardless. At least that's what happens when I manually |
The service, itself, there and in the build dir, as well |
Ah yeah my bad. |
Even, though Hyprland is installed in /usr/local, so the correct path should be Also, it didn't work. The services aren't restarting upon exiting, then re-entering the session. |
IMHO, might be a good idea to look, how GNOME and KDE do systemd stuff and adapt their practices to Hyprland. Correct session handling with systemd might as important stuff to implement, as were aquamarine and explicit sync, since both Arch Linux and NixOS - officially supported distros - use systemd. UPD: meson build seems to be broken too, as it defaults to /bin instead of /usr/local/bin. I, honestly, have no clue why CMake changed BINDIR variable value. |
Another insight - I suggest replacing @bindir@ variable inside hyprland-session.service with just /bin, like it was done in hypridle.service due to similar reasons (see hyprwm/hypridle#47 ). This way, we can fix #8340 along the way. |
Be aware that some DMs might not support desktop entry Exec quoting properly: Vladimir-csp/uwsm#39. I do not know if any upstream bug reports were made about this. |
Basically yes, but you left an extra quote there. Something like this, with bad-DM-proof comment. (oh, and the executable was also missing)
|
Probably, it's possible to wrap exec string in a script and |
@Vladimir-csp then is the Nixpkgs module implementation wrong for adding a |
There will be problems if one launches such entry with uwsm, it won't recognize itself. :) |
Sacrificing dm-compatibility isn't the best thing, but since display managers aren't officially supported, as stated in Hyprland wiki - probably, not that critical. Anyway, it's up to hyprwm team to decide. If the final decision is to use uwsm - I'll wait for systemd cleanup and then, will help to adjust the wiki. |
No, Comment field is perfectly valid. Or did you mean not adding More important choice is |
#8339 (comment) this example (edited) is DM-proof and consistent (except underscores). |
Oh wait, you meant that this string, with underscores, actually bypasses DM limitations and allows using the entry with them.
My bad |
Yes. I guess DMs did not expect the Report mentioned these:
|
Good. In this case, we can just replace existing hyprland-systemd.desktop with hyprland-uwsm.desktop. Or, we can just replace the contents of hyprland-systemd.desktop, as it's already configured to be installed with systemd deps. |
Some update about xpdh-service. Using @fufexan that's, probably, the reason why our own service didn't work as expected - we should've used a systemd command instead of hyprctl one. @Vladimir-csp I think makes sense to add a warning to uwsm "how to stop" readme section to not use compositor-side exit commands and use systemctl, instead. |
I've finally managed to start Hyprland using uwsm, but services are not started due to the absence of WAYLAND_DISPLAY.
uwsm_env-preloader output
Looks like WAYLAND_DISPLAY is not being exported. @Vladimir-csp any idea if this is a misconfig on my end? |
Are those services ordered
|
Ah yeah, why didn't I check that first. They're |
(moved to hyprwm/hyprland-wiki#850 (comment)) |
Rule of thumb: if something needs |
I found out that we've been doing hypr* services all wrong in Home Manager then. Almost all of them depend on graphical-session-pre. I will open PRs to fix those issues. Even the tray target we create wants it, which causes more problems down the line. There's also kdeconnect-indicator which does the same thing, probably an Xorg leftover.
I already do this in my configuration with a wrapper over |
ExecStart=@BINDIR@/Hyprland | ||
ExecStop=@BINDIR@/hyprctl dispatch exit |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This breaks using the current flake:
...
[Service]
Type=notify
ExecStart=bin/Hyprland
ExecStop=bin/hyprctl dispatch exit
ExecStopPost=systemctl --user unset-environment DISPLAY WAYLAND_DISPLAY HYPRLAND_INSTANCE_SIGNATURE XDG_CURRENT_DESKTOP
OnFailure=systemctl --user unset-environment DISPLAY WAYLAND_DISPLAY HYPRLAND_INSTANCE_SIGNATURE XDG_CURRENT_DESKTOP
OnSuccess=systemctl --user unset-environment DISPLAY WAYLAND_DISPLAY HYPRLAND_INSTANCE_SIGNATURE XDG_CURRENT_DESKTOP
...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We're scrapping the idea anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, that's odd, bindir is set in the mesonFlags: --bindir=/nix/store/81g3gcxh6ca0gk46r6p7zqna2fb3svd7-hyprland-0.44.0+date=2024-11-03_dirty/bin
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, after I built the package I got this
[Service]
Type=notify
ExecStart=/nix/store/hsx2dwp9agi54dvkkp7rhr9wgvar6d4h-hyprland-0.44.0+date=2024-11-03_403cd66/bin/Hyprland
ExecStop=/nix/store/hsx2dwp9agi54dvkkp7rhr9wgvar6d4h-hyprland-0.44.0+date=2024-11-03_403cd66/bin/hyprctl dispatch exit
ExecStopPost=systemctl --user unset-environment DISPLAY WAYLAND_DISPLAY HYPRLAND_INSTANCE_SIGNATURE XDG_CURRENT_DESKTOP
Restart=on-failure
Slice=session.slice
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very odd indeed. I was overriding the nixpkgs input, let me change that and see if we get the same eval:
/nix/store/8gww5vdnbxgvd8ian4m7z8rhixb0vsy9-hyprland-0.44.0+date=2024-11-03_d78bc75.drv
/nix/store/p1fx35kj1nw5w6swlz9xwhkbmjbknn55-hyprland-0.44.0+date=2024-11-03_d78bc75
It's different to your store path. Have you pushed all changes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I appreciate wanting to use ready-made solutions but they need to actually solve the problem properly in order to be viable.
Unless I'm missing something, it is not possible in uwsm to create a service that is part of the greater hyprland session but starts after the compositor is up. You cannot make it wantedBy graphical-session because it'd then be wantedBy any graphical session, regardless of the compositor. If you made it After
the compositor service other services After
the compositor service or the graphical-session wouldn't wait on your service, so that wouldn't work either.
I'd have expected uwsm to create a target for us that'd allow for this use-case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nevermind, it does create all sorts of targets. I didn't immediately find them because it appears to generate them dynamically rather than putting them into /etc/systemd/user/
?!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Vladimir-csp is it feasible to also create a {name}-session.target
that would be bound to wayland-session@{name}.target
?
@Atemu would this address your concern?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, as I said, it already does this, I just didn't see it because the units files weren't where I expected them to be.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using [email protected]
while target not yet existing is valid and works, but will result in a (harmless) warning from systemd.
Alternatively there is systemd-xdg-autostart-condition
, see examples
OnFailure=systemctl --user unset-environment DISPLAY WAYLAND_DISPLAY HYPRLAND_INSTANCE_SIGNATURE XDG_CURRENT_DESKTOP | ||
OnSuccess=systemctl --user unset-environment DISPLAY WAYLAND_DISPLAY HYPRLAND_INSTANCE_SIGNATURE XDG_CURRENT_DESKTOP |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/etc/systemd/user/hyprland-session.service:18: Unknown key 'OnFailure' in section [Service], ignoring.
/etc/systemd/user/hyprland-session.service:19: Unknown key 'OnSuccess' in section [Service], ignoring.
These go into the [Unit]
section.
I guess this can be closed in favor of #8376. |
This is much more robust than starting the session from the compositor config. It will also become the upstream-sanctioned method to start a hyprland session with proper systemd integration: hyprwm/Hyprland#8339
Describe your PR, what does it fix/add?
Adds more systemd targets.
Attempts to address NixOS/nixpkgs#347651.
Is there anything you want to mention? (unchecked code, possible bugs, found problems, breaking compatibility, etc.)
Untested. I don't know whether everything is hooked up as it should be.
We should probably implement a watchdog process like
gnome-session-monitor
.Is it ready for merging, or does it need work?
Needs reviews and testing.
@izmyname @solopasha @ anyone else