Systemd/UWSM

[fufexan]

This discussion should be used to ask questions or generally talk about Hyprland + Systemd/UWSM.

[autofool]

Is keeping our own service complicated? I don't understand why we need to add another dependency for something that already works.

[fufexan]

Besides being complex, I see no reason to duplicate work when uwsm already does all that we would've done through our homebrew solution, but is also not limited to just Hyprland.

And while homebrew systemd services would take care of the session management, uwsm goes a step further and also provides uwsm app, which runs programs as systemd units to separate them from the session.

[autofool]

Whats is uwsm check may-start? I'm using tty and bashrc for auto login and this always returns 1. If I remove this conditional from wiki then hyprland starts fine. Is it important?

[Vladimir-csp]

uwsm check may-start is a python process, it can only assume that its parent process is a shell and probe it externally. Login shell indicator is - in $0. This is how shells know they are being launched as a login shells.

Bash --login option is just a convenience that makes bash "behave" like a login shell (load profile files, etc), not all shells have such option. The main universal switch is the first character of $0.

[autofool]

How about env -a - bash?

EDIT:
This should work with all shells unless shell themselves overwrite $0 somehow.

[Vladimir-csp]

env -a is perfect! It's funny, every year I learn something new and surprisingly useful about env.

It should be env -a -bash bash, as I assume there are scripts out there that expect shell to be named properly, not just checking the first char.

[autofool]

I wonder if this is relevant enough to put on wiki or git readme. Bash has never failed me before however this time the --login option didn't do job properly. It didn't set name to '-bash'. Or is it the intended behavior? Or the name -bash was never set by bash in the first place but the system? Should we consider this a bug from bash side or a necessary preparation from user? I haven't used any other shells aside from bash to judge whether this is the norm.

[Vladimir-csp]

AFAIK $0 of the login shell is set by whatever launches the login shell. I.e. when logging in on a getty it is set by login.

Bash has --login option just to emulate login shell behavior.

[Vladimir-csp]

Regarding terminate-user vs terminate-session and analogs (comment):

Terminating session should work fine, but may leave some units in inconsistent state. My recommendation for users: if it works for you, use it. If it causes problems, use terminate-user.

I recently added ordering fix for flatpak apps which removed at least some part of these problems (Track and report them here: Vladimir-csp/uwsm#51).

[Ghosthree3]

Terminating session should work fine, but may leave some units in inconsistent state. My recommendation for users: if it works for you, use it. If it causes problems, use terminate-user.

Is it possible that these cases will ever be resolved entirely? terminate-user is really not a good option for anyone that uses their machine in any way outside of tty1, it even kills all active ssh/tmux sessions.
I personally have not yet experienced any issues using terminate-session, but there's no way I could ever use the terminate-user method if I did.

[Vladimir-csp]

Is it possible that these cases will ever be resolved entirely?

I sure do hope so: Vladimir-csp/uwsm#51

hyprwm/hyprland-wiki#868

[Ghosthree3]

Might I suggest code tagging Hyprland on the wiki page in the sentence, Choose Hyprland entry and you’re good to go., under the In tty/uwsm select whiptail method.
Maybe others are smarter than I am, but it wasn't immediately clear to me that the (uwsm-managed) version is only meant to be used when using some other launcher, not when using uwsm directly. In fact, it made sense to select it, since that's what I thought I wanted, a uwsm managed session. Perhaps even explicitly note NOT to use that selection.

[Vladimir-csp]

Technically you can choose any option in this situation, since uwsm knows how to deal with self in entries, but yes.

[Vladimir-csp]

hyprwm/hyprland-wiki#869

[izmyname]

Speaking of cursor variables (XCURSOR_ and HYPRCURSOR_) and UWSM_FINALIZE var, which exports them - is this really necessary to have them in hyprland.conf? What can break if, for example, XCURSOR_ will be put in ~/.config/uwsm/env and HYPRCURSOR_ - in ~/.config/uwsm/env-hyprland ?

[izmyname]

In other words (in case me, or someone else will be adding an entry to hyprland wiki), we can advise users to avoid setting any env vars in hyprland.conf entirely, and use environment.d, uwsm and uwsm-hyprland, correct?

@fufexan how would this possibly affect Hyprland, especially, hyprctl setcursor command?

[fufexan]

I don't think Hyprland cares. The variables are only useful to Hyprland anyway.
hyprctl setcursor isn't affected in any way. It's just a different way of setting the cursor theme and size.

[izmyname]

Good. In this case, we can advise uwsm users to export any vars to locations above and don't use hyprland.conf for this

[izmyname]

IMHO, since exporting env vars to uwsm is now officially advised method - there isn't much sense in having HYPRCURSOR_* and XCURSOR_* vars as UWSM_FINALIZE arguments.

[Vladimir-csp]

I'd keep them, at least for some time. It shouldn't cause any problems.

[b4shful]

I'm in the process of migrating, starting with my execs. I use end-4's dotfiles with some modifications here and there.

Here's where I'm at with execs.conf (expand to see the full file, but I will quote parts of it individually below):

execs.conf file

# You can make apps auto-start here
# Relevant Hyprland wiki section: https://wiki.hyprland.org/Configuring/Keywords/#executing
# Bar, wallpaper
exec-once = swww-daemon --format xrgb
exec-once = /usr/lib/geoclue-2.0/demos/agent
exec-once = ags &

# Core components (authentication, lock screen, notification daemon)

exec-once = gnome-keyring-daemon --start --components=secrets

# no longer used as using hyprpolkitagent instead (see below)
# exec-once = /usr/lib/polkit-gnome/polkit-gnome-authentication-agent-1 || /usr/libexec/polkit-gnome-authentication-agent-1

# systemd now handles this (configured by doing `systemctl --user enable --now hyprpolkitagent.service`)
exec-once = systemctl --user start hyprpolkitagent

# systemd now handles this (configured by doing `systemctl --user enable --now hypridle.service`)
# exec-once = hypridle

exec-once = hyprpm reload
exec-once = dbus-update-activation-environment --systemd WAYLAND_DISPLAY XDG_CURRENT_DESKTOP

# Audio
exec-once = easyeffects --gapplication-service

# Clipboard: history
# exec-once = wl-paste --watch cliphist store &
exec-once = wl-paste --type text --watch cliphist store
exec-once = wl-paste --type image --watch cliphist store

# Cursor
exec-once = hyprctl setcursor phinger-cursors-dark 24

Essentially, it seems I should be trying to either:

1. Prefix with uwsm app -- (maybe less applicable for these?)
2. Enable systemd user services for these instead (where available)

Bar, wallpaper etc.

exec-once = swww-daemon --format xrgb
exec-once = /usr/lib/geoclue-2.0/demos/agent
exec-once = ags &

No idea what to do with most of these

Gnome keyring

exec-once = gnome-keyring-daemon --start --components=secrets

I've read stuff about it starting automatically, not sure if I need to enable a service first before commenting this out, or if UWSM will already handle this?

These things

exec-once = hyprpm reload
exec-once = dbus-update-activation-environment --systemd WAYLAND_DISPLAY XDG_CURRENT_DESKTOP

I think the hyprpm reload was a workaround for something.
As for the dbus-update-blahblah, I assume that's most definitely not required with uwsm

The rest of it

# Audio
exec-once = easyeffects --gapplication-service

# Clipboard: history
# exec-once = wl-paste --watch cliphist store &
exec-once = wl-paste --type text --watch cliphist store
exec-once = wl-paste --type image --watch cliphist store

# Cursor
exec-once = hyprctl setcursor phinger-cursors-dark 24

Not sure.

[izmyname]

Bar, wallpaper etc.

exec-once = swww-daemon --format xrgb
exec-once = /usr/lib/geoclue-2.0/demos/agent
exec-once = ags &

Can prefix, geoclue thing will autostart automatically - it has a .desktop file in /xdg/autostart and uwsm does provide autostart via systemd-autostart-generator.

exec-once = dbus-update-activation-environment --systemd WAYLAND_DISPLAY XDG_CURRENT_DESKTOP

If you're using dbus-broker - drop this, entirely.

exec-once = easyeffects --gapplication-service

You can enable autostart in the easyeffects' settings - it'll create a .desktop file to autostart.

Clipboard: history

exec-once = wl-paste --watch cliphist store &

exec-once = wl-paste --type text --watch cliphist store
exec-once = wl-paste --type image --watch cliphist store

Yup, prefix with uwsm app --

exec-once = hyprctl setcursor phinger-cursors-dark 24

No need, prolly. If you're not sure - you can export this as a variable in .config/uwsm/env-hyprland

[Vladimir-csp]

gnome-keyring should have its own units, gnome-keyring-daemon.service, gnome-keyring-daemon.socket, that have WantedBy=graphical-session-pre.target (although they seem to lack ordering). Enable them, most likely they will work.

dbus-update-activation-environment --systemd WAYLAND_DISPLAY XDG_CURRENT_DESKTOP just drop this.

hyprctl/hyprpm invocations probably ok to leave in compositor's unit. Also stuff like wpctl, brightnessctl, etc.

Be aware that some commands may unexpectedly issue unit stopping notifications (bluetoothctl, podman). Wrap those or any other that do it.

Also see https://github.com/Vladimir-csp/uwsm/tree/master/example-units

[nicobonada]

Is there any reason I should keep using uwsm app -- instead of uwsm-app? The latter is supposed to be faster... are there any issues I should expect if I switch?

[JManch]

I've been using app2unit (which doesn't require a daemon) with no issues. Just need to set some env vars to replicate the the uwsm app behavior.

[Vladimir-csp]

All three are valid choices :)

[izmyname]

Rather a dull question, but anyway: do .config/uwsm/env and .config/uwsm/env-composior support #comments ?

[Vladimir-csp]

It's shell.

[nicobonada]

So, AFAICT, uwsm stop seems to shut everything down cleanly before exiting hyprland, which is very nice.

If I wanted to reboot or power off the system would just running e.g. reboot from inside hyprland also shut things down cleanly? Should I still do a uwsm stop first?

[Vladimir-csp]

reboot, or other shutdown commands, should bring everything down cleanly, since it's governed by systemd, and units are being stopped according to their ordering.