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?

[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]

A warning about env -a:
-a is a feature of env from GNU Coreutils specifically (along with most other options). It is not part of POSIX, other implementations of env may not have it.

[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.

[izmyname]

In what order are environment.d/*.conf, uwsm/env and uwsm/env-hyprland sourced? Does UWSM_FINALIZE_VARNAMES affect the order?

[Vladimir-csp]

environment.d/*.conf is governed by systemd, see man environment.d. It is applied at the start of user manager and whenever daemon-reload is performed, acting as default background state of services' environment.

uwsm/env* are loaded in order of increasing priority: by dirs (system data reversed, system config reversed, user config), in each: generic then by desktops reversed.

UWSM_FINALIZE_VARNAMES has nothing to do with those parts of environment. It only affects what uwsm finalize does.

[rickyelopez]

Is there anything I can do to get my tmux sessions to persist across a uwsm stop and hyprland restart?

[Vladimir-csp]

Enable linger on user, run tmux as a service or scope under app.slice
Something like this:

loginctl enable-linger "$USER"
systemd-run --user -u tmux.service -- tmux -D

[cicero-violate]

is it safe to say that all my app variables should have uwsm app -- ?

eg.
$fileManager = uwsm app -- ~/scripts/kitty_with_font.sh -e zsh -c 'yazi; exec zsh'
$float_terminal = uwsm app -- kitty
$editor = uwsm app -- neovide
'$menu = uwsm app -- rofi -m $(hyprctl monitors | awk -v RS= '/focused: yes/ {print $2}') -show drun

bind = $mainMod, E, exec, $editor
bind = $mainMod, Q, exec, $terminal
bind = $mainMod, A, exec, $menu
bind = $mainMod, O, exec, [float] $fileManager

also, as with the case of adding rule arguments outside of the "uwsm app --"
(eg. [float] in
bind = $mainMod, O, exec, [float] $fileManager)

am i doing it wrong because the uwsm app -- statement is inside $fileManager
and the [float] is outside of that?

[izmyname]

It's safe - you're just detaching them from Hyprland and make systemd manage them. This is, for example, what happens - when you create an autostart .desktop entry in ~/.config/autostart

[Vladimir-csp]

I wouldn't wrap rofi itself, but commands it executes. -run-command 'uwsm app -- {cmd}'.
Plus do not forget that with uwsm app (or app2unit) you can launch by desktop entry id and get fancy unit descriptions, automatic launch in terminal.

[cicero-violate]

gotcha. thanks guys. i'll make those changes right away! i'm going full configs on .desktops openings moving forward.and merry christmas!

[izmyname]

Speaking of flatpaks and org.freedesktop.Background. Since this interface, from my understanding, provides a way for flatpaks to 'talk' to the compositor via dbus interface and uwsm takes care of autostarting apps by activating necessary services - is there a theoretical possibility to implement such interface within uwsm, instead of xdph?

[izmyname]

@Vladimir-csp sorry for bothering, but it would be interesting to hear your opinion on such possibility.

[Vladimir-csp]

Not sure I fully understand how this works, but this is an interface of a portal.

commandline (as)
Commandline to use add when autostarting at login. If this is not specified, the Exec key from the desktop file will be used.

So there's a desktop entry somewhere, and an app is requesting from portal to be added to autostart either via a command, or its desktop file... Is this something that a portal should do?

[izmyname]

Is this something that a portal should do?

With desktop environments - yes, but they have their own means (packages, like xfdesktop for xfce) to start necessary systemd targets, services etc. Since uwsm acts as a desktop-session for wayland compositors, I thought it might be, in theory, possible or, at least, worth to look into.

Also, here, in response - why xdg-desktop-portal-gtk itself doesn't handle autostart, there's a response, stating that this is because

backend doesn't know your desktop environment's preferred way to set the background.

As I understand, uwsm, in this case, acts as a 'desktop environment' as it handles the whole session.

[Magnitudexx]

Is it normal to have several gigs of ram usage at cold boot

[BlueskyFR]

Is there a clear reason why uwsm should be used? As it seems extra work for no real benefit IMO

[izmyname]

XDG autostart, no 90 sec shutdowns, ability to enable systemd services, that depend on graphical session.

[izmyname]

There's an idea to turn hyprlock into a full-featured greetd greeter hyprwm/hyprlock#731. From my understanding - it should work like this: greetd.service launches a system-wide hyprland instance, and that hyprland instance executes hyprlock. The question is - how system-wide hyprland and hyprlock are going to be managed from systemd perspective and wouldn't such setup defeat the point of using uwsm, especially in case of exec-once = hyprlock ?

[Vladimir-csp]

As far as I understand, greeter session is a thing in itself and should end before user session begins. It's not Xorg which was running as root and continued running throughout user sessions. Greetd starts greeter (which is a compositor + login GUI), user logs in, greeter ends, greetd starts user session.

[izmyname]

greeter ends

Afaik a user session, started from a display manager is a child process of said display manager, and if a display_manager.service gets stopped within said user session - the user session exits, and display_manager.service gets reloaded. At least, it was the case with wayland-native sddm, so either I don't quite understand the concept, or a greeter session is rather persistent and exec-once = hyprlock isn't going to be managed by systemd and has the potential to hang the system on shutdown, since it's going to be called on a session exit - right before shutdown. Unless, greetd.service manages to cleanly kill it, along with system-wide Hyprland

[Vladimir-csp]

From man greetd:

The default session is started on launch ..., and started again whenever no session is running, such as when the user logs out.

An IPC socket is exposed to this greeter, as reported by GREETD_SOCK. The greeter can use this to create, authenticate and finally start a session. ...

Once the greeter has requested the start of a session and terminated itself, greetd will start the new session. Once this session terminates, the process starts over.

greetd makes no assumptions about any sessions, including the greeter. They can be text-based, running in the active console, or full-on graphical environments.

So hyprland with hyprlock, if launched as a greeter, should communicate to greetd who authenticated and what session to launch next, then peace out.

[izmyname]

That's reassuring. Let's hope it's going to work, as expected.

[xdevfaheem]

I'm wondering when to exec-once and when to enable systemd service units? like for dunst? it's service unit couldn't be enabled unless add-wants graphical-session.target.

and btw I prefer using runapp, which launch apps service unit by default. So would i ok, if i launch those service intend to autostart with systemd enable ... with exec-once = runapp app --slice (app/bg/session-graphical.slice)

Which one should i go with?

And also one more question, some service unit files, set slice=session.slice as opposed to uwsm's session-graphical.slice, what's with that?

[Vladimir-csp]

I'm wondering when to exec-once and when to enable systemd service units? like for dunst? it's service unit couldn't be enabled unless add-wants graphical-session.target.

Whatever floats your boat.
If an app provides a unit, I'd go with that, even if it requires some drop-ins to improve. Dunst default unit seems to require adding wants and After=graphical-session.target, but it is also a dbus-activated service, so unit name in theory should matter.

and btw I prefer using runapp, which launch apps service unit by default. So would i ok, if i launch those service intend to autostart with systemd enable ... with exec-once = runapp app --slice (app/bg/session-graphical.slice)

For uwsm app and app2unit you can change default app unit type with corresponding env vars. As long as there are no conflicts between static autostarted units and those you create with launch wrappers, you are good to go. Check journal to see if there are problems.

And also one more question, some service unit files, set slice=session.slice as opposed to uwsm's session-graphical.slice, what's with that?

*-graphical.slice are custom slices that uwsm uses to group units and propagate stop on session end. Alternative to that is having PartOf=graphical-session.target, After=graphical-session.target or any other means of receiving stop action in the right order in a unit. Then any slice can be used.

[xdevfaheem]

Ah cool... got'em all, thanks for clear reply. So it is recommended to use service unit if an app provides, doesn't matter its slice as long it has Partof, After as graphical-session.target to receive a proper stop signal before compositor shuts off. right?

xdg autostart, systemd user-level service unit, exec-once with app launcher wrapper, etc... lots of options to launch an app in separate unit, as to prevent it from starting as child process with compositor's. I've been drowning with doubts lately, your docs are very clear and helpful. Thanks!

Couple more questions if you don't mind,

From your repo's readme,

Compositor itself runs in session.slice which has priority in some resource allocation. It would be a bad practice to accumulate all apps there, and extremely bad practice to accumulate processes inside compositor's unit itself.

1. As stated, obviously it is bad to launch apps within compositors process, i believe that's the whole point of having UWSM, it is also bad to run apps in session.slice but i see lot of applications that are intend to autostart with systemd has Slice=session.slice in their respective service files. like hyprsunset, hyprpolkitagent and even dust, ... well, wouldn't that be an issue to add apps in session.slice process?

2. Would it be okay to launch apps service via exec-once with app launcher wrappers but as service unit and also with appropriate custom slice (app, bg, session), for example: exec-once = runapp dunst --slice "session-grahical.slice" , rather than setting up it's service (maybe add-wants and some drop-ins) and enabling it via systemd?

If I just pass app's command to exec-once, like exec-once = dunst. I think it will be launched within compositors process, but when wrapped and launched as service (along with appropriate slice), then it should be launched as seperate service (not a compositor's child process). Isn't it what enabling it as systemd service supposed to do? If so, It should be okay, right?

[xdevfaheem]

As you guys can see, Hyprland (the compositor), dunst, hyprsunset, clipboard service, and even my terminal is launched as separate service (coz of lauching it as service with runapp), (i have disabled hyprpolkit btw).

This is how it is supposed be launched in proper wayland setup, right?

[Vladimir-csp]

Maybe "child process of compositor" wasn't the correct choice of words. Scoped processes are still children of those which forked them, but the point is to assign them to a different unit.

As stated, obviously it is bad to launch apps with compositors process, i believe that's the whole point of having UWSM, it is also bad to run apps in session.slice but i see lot of applications that are intend to autostart with systemd has Slice=session.slice in their respective service files. like hyprsunset, hyprpolkitagent and even dunst-project/dunst#1397, ... well, wouldn't that be an issue to add apps in session.slice process?

Usually it's apps requiring responsiveness and RT. Like pipewire stuff that you would not like to be stuttering. Dunst's choice may be a bit strange IMHO. What I meant: it is not a good practice to just shove all/random apps there.

Would it be okay to launch apps service via exec-once with app launcher wrappers but as service unit and also with appropriate custom slice (app, bg, session), for example: exec-once = runapp dunst --slice "session-grahical.slice" , rather than setting up it's service (maybe add-wants and some drop-ins) and enabling it via systemd?

If it would not produce any conflicts with static units, then why not. Also consider unit names, you may want to set a name without random component to make a single-instance service.

If I just pass app's command to exec-once, like exec-once = dunst. I think it will be launched within compositors process, but when wrapped and launched as service (along with appropriate slice), then it should be launched as seperate service (not a compositor's child process). Isn't it what enabling it as systemd service supposed to do? If so, It should be okay, right?

Yes. And whether you launch it as scope (child of compositor, but in a separate unit) or service (child of systemd, also separate unit) - does not matter in terms of correctness, both are fine, choose whatever suits your needs.

[xdevfaheem]

Maybe "child process of compositor" wasn't the correct choice of words. Scoped processes are still children of those which forked them, but the point is to assign them to a different unit.

Hmm... so launching apps as scope process (child of compositor) is fine as long as it launched in separate unit. So i guess it is only bad to launch apps as child of compositor process and within it's unit.

Usually it's apps requiring responsiveness and RT. Like pipewire stuff that you would not like to be stuttering. Dunst's choice may be a bit strange IMHO. What I meant: it is not a good practice to just shove all/random apps there.

Got it 👍

If it would not produce any conflicts with static units, then why not. Also consider unit names, you may want to set a name without random component to make a single-instance service.

I'm sorry, i couldn't get what you mean here.

Yes. And whether you launch it as scope (child of compositor, but in a separate unit) or service (child of systemd, also separate unit) - does not matter in terms of correctness, both are fine, choose whatever suits your needs.

Cool so it doesn't matter the apps are launched as service (runapp default)/scope (uwsm app default) as long it is in separate unit , and apps launched via exec-once as service (as the example i gave above) should also have no issue with receiving proper shutdown signal right?

I'm wondering, what is the difference between apps launched via app launcher (as service) in exec-once and service enabled via systemd?

So can you layout standard specifications or supposedly a good/encouraged way to launch service that are intend to autostart (systemd or exec-once ?!) and normal daily drive GUI apps (app launchers?). I believe that would very to helpful to me and as well as whoever wandering on this subject.

Ig I'm asking too much, sorry about that, just curious. AIs are not good on these subject to rely on them.

[spartako]

Chromium is always asking to restore tabs since it didn't close cleanly when running uwsm stop. I have it started via uwsm app -- /usr/share/applications/chromium.desktop. What gives? Anyone else having this kind of issue with electron apps?

[spartako]

Will do, thanks for your time.

[rickyelopez]

Is there a clever way of handling this when launching chromium (or in my case Brave) through rofi, where rofi has -run-command uwsm-app -- {cmd}? Can I just modify the .desktop and prefix the exec command with uwsm-app -t service --? Or will that conflict with the uwsm-app -- that rofi prepends?

[Vladimir-csp]

You want to transparently run chromium as a service, while other apps as scopes?

[rickyelopez]

Well I wouldn't say I want to... :) From the above conversation, it looks like the only way to get chrome to exit cleanly (i.e. load previous session on next startup rather than prompting to restore) is to run it as a service, right? I usually launch chrome with Rofi, though... Is there a better way to implement the above suggestion (uwsm app -t service -- chromium.desktop)?

[Vladimir-csp]

Maybe not the most elegant solution, but it can give some flexibility: a wrapper script (for a wrapper, lol) to use in rofi -run-command "script {cmd}":

#!/bin/sh
case "${1##*/}" in
[Cc]hromium) exec uwsm-app -t service -- "$@" ;;
*) exec uwsm-app -- "$@" ;;
esac

[noisegrrrl]

Is there a way to start uwsm/hyprland as a service itself?
The idea is to be able to tie the different services like hyprpolkitagent for instance to the compositor like is described for niri here: https://github.com/YaLTeR/niri/wiki/Example-systemd-Setup

Basically I'd like to be able to have 2 differents DE/WM cohabiting on the same system each with their own services, but as uwsm/hyprland works out of the box I'm not sure how/if it is possible?

[noisegrrrl]

I think I might have found the answer by using [email protected] but I could use confirmation that it's a good way to go about things.

[Vladimir-csp]

Any compositor you start via uwsm is a service that you can use in dependencies. But ExecCondition with systemd's native XDG autostart filter is IMHO a better solution. Anyway, you can find info on both ways in example-units

[noisegrrrl]

Thanks, I'll try that way!

[Askelhardd]

I am using hyprland in cachyOS and I can't make uwsm work...
I unticked cachyOS custom hyprland config, but the rest is standard, uwsm was preinstalled
I am running hyprland "uwsm managed" through SDDM

But anytime I try to run anything with uwsm app -- thunar (or this exec with a bind in my hypr config)
and I do pstree -apl | grep -B 20 'thunar'
It's always running as a child of my shell, not uwsm...

[Vladimir-csp]

Check systemctl --user status and search for thunar process. It should be in its own scope unit. If it is, then everything works as it should.

[Askelhardd]

right, I got alacritty->zsh->thunar under systemd, and not under hyprland
so it looks good actually

[Vladimir-csp]

You can use services instead of scopes to have all apps' processes be children of systemd, plus some more control over units. But process tree is not that important, units and file descriptors are.

[Carl-Llewellyn]

I have the same issue after an upgrade. Some people got it to work with a downgrade of UWSM:

https://bbs.archlinux.org/viewtopic.php?id=307539

Didn't work for me. Might work for you!

[Vantesh]

@Vladimir-csp When I stop Hyprland with uwsm stop or loginctl terminate-user "", VS Code doesn’t exit cleanly. I have to wait until Hyprland marks it as “not responding” before I can terminate it. Is there a way to fix this?

[Vantesh]

This is what i get when i stop it with uuctl

also app2unit -p SendSIGHUP=true -- code . does not help either

[Vladimir-csp]

"Task failed successfully" lol.

With no code running, save units state, run code, save state again and show difference. Which units are created?

systemctl --user status > /tmp/1
app2unit -- code . &
systemctl --user status > /tmp/2
diff -u --color /tmp/1 /tmp/2

Is it one or several?

Also does running it as service help? app2unit -t service -- code .

[Vantesh]

Here is the diff
log.txt

Also does running it as service help? app2unit -t service -- code .

i have APP2UNIT_TYPE=service in uwsm env file

[Vladimir-csp]

Then, there is nothing simple to do here, code just doesn't handle SIGTERM well.

[Vantesh]

Then, there is nothing simple to do here, code just doesn't handle SIGTERM well.

Idk if it's a good idea or not but here is what i have done to make it work. So far i haven't seen the popup and vscode restores its windows on login.

#!/usr/bin/env bash

set -euo pipefail

USER_NAME="${USER:?No user detected}"

# Kill VS Code
pid=$(hyprctl clients -j | jq -r '.[] | select(.class=="code") | .pid' | head -n 1)

if [[ -n "$pid" ]]; then
    kill "$pid"
fi

exec loginctl terminate-user "$USER_NAME"

[variasdesign]

Hello. I've been using Hyprland along with uwsm for a few months now. I've noticed in two separate systems with similar dotfiles that occasionally uwsm stop hangs until a timeout passes. Looking in my user journal, I see the timeout happens with an Alacritty service unit, most of the time a terminal window I had open at shutdown. I use Alacritty along with Zellij and AFAIK there's no fancy reason why it should hang. I'm looking for a way to diagnose the problem, because journalctl is not giving me much:
uwsm-log.txt

Thanks for any help.

[Vladimir-csp]

Try reproducing by just stopping a particular Alacritty unit that you suspect might hang. This will show if the issue is related to shutdown at all. Judging from the log, it seems that Alacritty is terminated successfully, but its children for some reason linger ignoring initial SIGTERM.

[Fozzyishere]

I have the same problem as this post on reddit: https://www.reddit.com/r/hyprland/comments/1kbbp8i/after_every_boot_firefox_starts_as_if_the/

This kinda give me a workaround to fix the issue #8459 (comment)

What I'm worrying right now is that if there are more apps than just firefox/chrome launching its main process into a seperate scope, how can i detect it? Should i just launch everything into a service or something else?

Thanks to anyone reading this.

[Vladimir-csp]

Choosing scope/service might depend on what you want from app's input/output and process inheritance. Running something from a terminal is better with a scope. From a launcher or a keybind - might be better with a service. Nothing to really worry about, plus trial and error.