Greetings. I installed sway-systemd on Debian along with Sway and Waybar. Waybar starts normally via waybar.service , however if I exit the Sway session (I'm using greetd + tuigreet) Waybar tries to start before Sway and thus fails. I tried changing graphical-session.target to sway-session.target in waybar.service , but to no avail. The only way out is to activate waybar.service , but then Waybar starts running all the time, for example, it cannot be terminated (it will restart). Please tell me if there is a solution to this problem?

Detection of apps for assign-cgroups script is currently completely reliant on an i3 IPC interface provided by the compositor/window manager. That is fine and it should cover most of resource intensive applications.

Assuming that the autostart is already handled by systemd-xdg-autostart-generator, there are still a few things I'd like to put into cgroups:

• special applications (layer-shell)
• apps that are started minimized to tray (i.e. some heavy background process with a tray icon to control).
• ...?

I don't think this bug has been recently introduced by sway-systemd itself, most likely in some sway change, but the problem is still here. Recently the services attached to the sway-session target are being started before sway is ready, resulting in errors such as Exception: Failed to retrieve the i3 or sway IPC socket path and cannot open display:
Most of these issues cause the services to restart over and over until sway is ready, which is a bit annoying, and some don't restart at all and need to be restarted manually after sway has fully loaded.

Is there any way to delay starting the services attached to the sway-session target until sway has finished starting and is accepting connections?

The foot terminal is adding systemd socket activation:

https://codeberg.org/dnkl/foot/pulls/890

What's the best way to set up the socket? Note that it's a template unit, so one socket can be set up per Wayland display (relating to #12).

Since it's a template unit, it doesn't seem like an [Install] block will work. It seems that start needs to explicitly be called on the socket file, like systemctl start foot-server@$WAYLAND_DISPLAY.socket.

This is something that this project could potentially take care of, but this project is otherwise agnostic towards specific systemd services, so maybe that's not a feature that's desirable to add here.

If starting the foot socket were to be handled here, I see a couple options:

1. Unconditionally try to start the foot socket and ignore the error code if the socket can't be found (since not everyone will use foot). This is zero-configuration, runs and the background and doesn't really block anything else from happening. Because it's just launching socket activation and not the the foot server, there's very little overhead.
2. Add an option or configuration to explicitly enable the foot server. If configured, attempt to start the unit.

Given the somewhat unique case, I think it's worth considering attempting to start the foot socket file.

As a side note on fast foot can launch in client server mode, it's about 10x faster than Alacritty for this test, taking only 10 ms to run!

 time alacritty -e /bin/echo 42
__________________________________________
Executed in   91.19 millis    fish           external
 
❯ time footclient -e /bin/echo 42
__________________________________________
Executed in   10.38 millis    fish           external

This project embeds some environment variables in a shell script. It advises modifying the shell script to update the environment variables, which is not ideal.

Is there a better way?

Is systemd's "environment.d" a possible solution?
https://www.freedesktop.org/software/systemd/man/environment.d.html

As a disclosure, I currently use a shell script to set environment variables when starting sway, which I'll include below.

One thing you'll see in this snippet is that there are a number of other environment variables are useful to get toolkits or apps to prioritize Wayland over X11. These would be common modifications to the script shipped here.

The second thing you'll notice is that I start gnome-keyring here. I tried to run gnome-keyring as a systemd service but could not get it to work, I think because it needs to export an environment variable in time for other apps that are launched to receive it.

So consider that a challenge to test this project and how it handles environment variables-- can it work with gnome-keyring-daemon to export SSH_AUTH_SOCK early enough for terminal apps to access it?

#!/usr/bin/env sh
# From here: https://github.com/nullgemm/ly/issues/228
eval $(/usr/bin/gnome-keyring-daemon --start)
export SSH_AUTH_SOCK

export TERMINAL="alacritty"
export _JAVA_AWT_WM_NONREPARENTING=1
export QT_AUTO_SCREEN_SCALE_FACTOR=1
export QT_QPA_PLATFORM=wayland
export QT_WAYLAND_DISABLE_WINDOWDECORATION=1
export MOZ_ENABLE_WAYLAND=1
export MOZ_WEBRENDER=1
export MOZ_ACCELERATED=1
export BEMENU_BACKEND=wayland
export GTK_THEME=Adwaita:dark

/sbin/sway

(If it matters, I'm currently using ly as my display manager).

We're doing this for Fedora, after all...

An arbitrary process of user_u or xguest_u cannot connect to the user session bus. Nothing works, DBus activation included, but the python backtrace is scary and abrt attempts to report it.

assign-cgroups.[24758]: Traceback (most recent call last):
assign-cgroups.[24758]:   File "/usr/libexec/sway-systemd/assign-cgroups.py", line 197, in <module>
assign-cgroups.[24758]:     asyncio.run(main())
assign-cgroups.[24758]:   File "/usr/lib64/python3.9/asyncio/runners.py", line 44, in run
assign-cgroups.[24758]:     return loop.run_until_complete(main)
assign-cgroups.[24758]:   File "/usr/lib64/python3.9/asyncio/base_events.py", line 642, in run_until_complete
assign-cgroups.[24758]:     return future.result()
assign-cgroups.[24758]:   File "/usr/libexec/sway-systemd/assign-cgroups.py", line 189, in main
assign-cgroups.[24758]:     bus = await MessageBus().connect()
assign-cgroups.[24758]:   File "/usr/lib/python3.9/site-packages/dbus_next/aio/message_bus.py", line 122, in __init__
assign-cgroups.[24758]:     super().__init__(bus_address, bus_type, ProxyObject)
assign-cgroups.[24758]:   File "/usr/lib/python3.9/site-packages/dbus_next/message_bus.py", line 86, in __init__
assign-cgroups.[24758]:     self._setup_socket()
assign-cgroups.[24758]:   File "/usr/lib/python3.9/site-packages/dbus_next/message_bus.py", line 569, in _setup_socket
assign-cgroups.[24758]:     raise err
assign-cgroups.[24758]:   File "/usr/lib/python3.9/site-packages/dbus_next/message_bus.py", line 542, in _setup_socket
assign-cgroups.[24758]:     self._sock.connect(filename)
assign-cgroups.[24758]: ConnectionRefusedError: [Errno 111] Connection refused

assign-cgroups.[32158]: Traceback (most recent call last):
assign-cgroups.[32158]:   File "/usr/lib/python3.9/site-packages/dbus_next/_private/address.py", line 78, in get_session_bus_address
assign-cgroups.[32158]:     with open(dbus_info_file_name) as f:
assign-cgroups.[32158]: FileNotFoundError: [Errno 2] No such file or directory: '/home/xguest/.dbus/session-bus/3e22a354446748f1a4ba39a4c8ffb225-2'
assign-cgroups.[32158]: During handling of the above exception, another exception occurred:
assign-cgroups.[32158]: Traceback (most recent call last):
assign-cgroups.[32158]:   File "/usr/libexec/sway-systemd/assign-cgroups.py", line 197, in <module>
assign-cgroups.[32158]:     asyncio.run(main())
assign-cgroups.[32158]:   File "/usr/lib64/python3.9/asyncio/runners.py", line 44, in run
assign-cgroups.[32158]:     return loop.run_until_complete(main)
assign-cgroups.[32158]:   File "/usr/lib64/python3.9/asyncio/base_events.py", line 642, in run_until_complete
assign-cgroups.[32158]:     return future.result()
assign-cgroups.[32158]:   File "/usr/libexec/sway-systemd/assign-cgroups.py", line 189, in main
assign-cgroups.[32158]:     bus = await MessageBus().connect()
assign-cgroups.[32158]:   File "/usr/lib/python3.9/site-packages/dbus_next/aio/message_bus.py", line 122, in __init__
assign-cgroups.[32158]:     super().__init__(bus_address, bus_type, ProxyObject)
assign-cgroups.[32158]:   File "/usr/lib/python3.9/site-packages/dbus_next/message_bus.py", line 73, in __init__
assign-cgroups.[32158]:     get_bus_address(bus_type))
assign-cgroups.[32158]:   File "/usr/lib/python3.9/site-packages/dbus_next/_private/address.py", line 98, in get_bus_address
assign-cgroups.[32158]:     return get_session_bus_address()
assign-cgroups.[32158]:   File "/usr/lib/python3.9/site-packages/dbus_next/_private/address.py", line 81, in get_session_bus_address
assign-cgroups.[32158]:     raise InvalidAddressError(f'could not open dbus info file: {dbus_info_file_name}')
assign-cgroups.[32158]: dbus_next.errors.InvalidAddressError: could not open dbus info file: /home/xguest/.dbus/session-bus/3e22a354446748f1a4ba39a4c8ffb225-2

An arbitrary process of staff_u is allowed to connect to the bus but has no permission to start transient units:

systemd[27184]: selinux: avc:  denied  { start } for auid=1002 uid=1002 gid=1002 path="/run/user/1002/systemd/transient/app-Alacritty-27295.scope" cmdline="/usr/bin/python3 /usr/libexec/sway-systemd/assign-cgroups.py" scontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023 tcontext=staff_u:object_r:user_tmp_t:s0 tclass=service permissive=0
assign-cgroups.[27260]: WARNING:root:retry: assign_scope failed (1/3): SELinux policy denies access.
systemd[27184]: selinux: avc:  denied  { start } for auid=1002 uid=1002 gid=1002 path="/run/user/1002/systemd/transient/app-Alacritty-27295.scope" cmdline="/usr/bin/python3 /usr/libexec/sway-systemd/assign-cgroups.py" scontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023 tcontext=staff_u:object_r:user_tmp_t:s0 tclass=service permissive=0
assign-cgroups.[27260]: WARNING:root:retry: assign_scope failed (2/3): SELinux policy denies access.
systemd[27184]: selinux: avc:  denied  { start } for auid=1002 uid=1002 gid=1002 path="/run/user/1002/systemd/transient/app-Alacritty-27295.scope" cmdline="/usr/bin/python3 /usr/libexec/sway-systemd/assign-cgroups.py" scontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023 tcontext=staff_u:object_r:user_tmp_t:s0 tclass=service permissive=0
assign-cgroups.[27260]: WARNING:root:retry: assign_scope failed (3/3): SELinux policy denies access.
assign-cgroups.[27260]: ERROR:CGroupHandler:Failed to modify cgroup for Alacritty
assign-cgroups.[27260]: Traceback (most recent call last):
assign-cgroups.[27260]:   File "/usr/libexec/sway-systemd/assign-cgroups.py", line 182, in _on_new_window
assign-cgroups.[27260]:     await self.assign_scope(app_id, pid)
assign-cgroups.[27260]:   File "/usr/libexec/sway-systemd/assign-cgroups.py", line 74, in decorated
assign-cgroups.[27260]:     raise err
assign-cgroups.[27260]:   File "/usr/libexec/sway-systemd/assign-cgroups.py", line 68, in decorated
assign-cgroups.[27260]:     return await func(*args, **kwargs)
assign-cgroups.[27260]:   File "/usr/libexec/sway-systemd/assign-cgroups.py", line 166, in assign_scope
assign-cgroups.[27260]:     await self._sd_manager.call_start_transient_unit(
assign-cgroups.[27260]:   File "/usr/lib/python3.9/site-packages/dbus_next/aio/proxy_object.py", line 92, in method_fn
assign-cgroups.[27260]:     BaseProxyInterface._check_method_return(msg, intr_method.out_signature)
assign-cgroups.[27260]:   File "/usr/lib/python3.9/site-packages/dbus_next/proxy_object.py", line 61, in _check_method_return
assign-cgroups.[27260]:     raise DBusError._from_message(msg)
assign-cgroups.[27260]: dbus_next.errors.DBusError: SELinux policy denies access.

• The python code should be able to exit cleanly with an error message instead of crashing with uncaught exception.
• The python code should be able to detect that it has no permission to assgn scopes and exit cleanly
• The custom selinux policy should permit starting transient units

When starting foot --server as a systemd user service, the resulting foot clients are missing many environment variables which are present in terminals not started as a user service (starting alacritty directly). I believe this is because the session.sh only exports a small number of variables to systemd and dbus, but am not sure the best course of action to resolves this.
#6 related

Verification of expected functionality with a sway config that does not include other systemctl commands.
Something I'd like to put into a Fedora OpenQA test suite for sway if we ever start implementing one.

After the compositor start

• systemctl --user is-active graphical-session.target is active
• systemctl --user show-environment | grep WAYLAND_DISPLAY matches current WAYLAND_DISPLAY
• systemctl --user show-environment | grep XDG_CURRENT_DESKTOP is sway
• Launch alacritty and verify that the process is placed under app.slice/app-Alacritty.slice/app-Alacritty-$PID.scope

If xdg-desktop-portal-wlr is installed

• Verify that it is running if the xdg-desktop-portal is started
• Take a screenshot using portal APIs (using this script for example)
• Try Screen capture demo with firefox-wayland Fedora package (idk if it's even possible to automate this in OpenQA).

After logout (using another session to keep systemd --user alive)

• systemctl --user is-active graphical-session.target is inactive
• systemctl --user show-environment | grep WAYLAND_DISPLAY returns nothing
• systemctl --user show-environment | grep XDG_CURRENT_DESKTOP returns nothing
• maybe check if the services bound to graphical-session.target were stopped

Not really sure how I caused this issue, it occurred after starting spotify with rofi. assign-cgroups.py crashed with the following output:

ERROR:assign-cgroups:Failed to modify cgroup for None
Traceback (most recent call last):
  File "/usr/lib/sway-systemd/assign-cgroups.py", line 219, in _on_new_window
    await self.assign_scope(app_id, pid)
  File "/usr/lib/python3.9/site-packages/tenacity/_asyncio.py", line 75, in async_wrapped
    return await fn(*args, **kwargs)
  File "/usr/lib/python3.9/site-packages/tenacity/_asyncio.py", line 38, in __call__
    do = self.iter(retry_state=retry_state)
  File "/usr/lib/python3.9/site-packages/tenacity/__init__.py", line 367, in iter
    return fut.result()
  File "/usr/lib/python3.9/concurrent/futures/_base.py", line 438, in result
    return self.__get_result()
  File "/usr/lib/python3.9/concurrent/futures/_base.py", line 390, in __get_result
    raise self._exception
  File "/usr/lib/python3.9/site-packages/tenacity/_asyncio.py", line 41, in __call__
    result = await fn(*args, **kwargs)
  File "/usr/lib/sway-systemd/assign-cgroups.py", line 186, in assign_scope
    app_id = escape_app_id(app_id)
  File "/usr/lib/sway-systemd/assign-cgroups.py", line 66, in escape_app_id
    return app_id.replace("-", "\\x2d")
AttributeError: 'NoneType' object has no attribute 'replace'

--- edit
Didn't crash, I was wrong, so this issue is probably harmless and can be closed (I think?)

Hello and thanks for that awesome project! I have a problem with locale1-xkb-config. When it enabled (and launched with https://github.com/alebastr/sway-systemd/blob/main/config.d/95-system-keyboard-config.conf.in), I'm unable to change my keyboard layout, variant, and other parameters in Sway config. localectl output:

System Locale: LANG=ru_RU.UTF-8
       VC Keymap: us
      X11 Layout: us
       X11 Model: pc105

And this is in my Sway config:

# Keyboard layout
  input type:keyboard {
   xkb_layout us,ru
   xkb_options grp:caps_toggle
}

Currently, neither of these config files:

• 95-system-keyboard-config.conf.in
• 95-xdg-desktop-autostart.conf.in

Are being added to the configs list in meson.build when building with the following flags respectively:

• -Dlocale1=true
• -Dautostart=true

Does this make any sense?

After installation of version 0.4 hotkeys for keyboard layot switch ceased to work. Part of sway config responsive for that functionality looks that:

input type:keyboard {
    xkb_layout us,ru
    xkb_options grp:rctrl_toggle,compose:ralt
}

Highly likely this script is the cause. I dunno exactly which part of the logic of the script causes that, could you please check/verify somehow?

Another run at #6 .

Would you consider modifying session.sh so that it looks for an "Environment" file in a pre-defined location, and, if the file exists, sources the variables in that file and then adds them to the $VARIABLES list alongside the default variables hardcoded in the script and those passed in via -E?

This has the advantage of leveraging a broadly-used format (i.e, you can crib from people using .profile or /etc/environment.d). It also should mean that the file won't get overwritten when sway-systemd is upgraded (unlike changes to -E in 10-systemd-session.conf).

I stuck this language into my session.sh and, while it's not pretty it does seem to work:

set_var(){
        . ${1}
        while read -r line; do
                if [[ $(echo $line | grep -v ^#) ]]; then
                        line=${line%=*}
                        export ${line}
                        VARIABLES="${VARIABLES} ${line}"
                fi
        done < ${1}
}

if [[ -e ~/.config/sway-systemd/env ]]; then
        set_var ~/.config/sway-systemd/env
fi

Similarly, would it be possible to do something similar for the transient scope units created by assign-cgroups.py? It seems one could parse an Environment file and submit the name/value pairs via the systemd d-bus API's SetEnvironment() method. Since a lot of the commonly-used environment variables are used to persuade GUI programs to use wayland, this might prove useful.

It would be helpful if there some brief docs that covered what files this project provides and how they fit together. For example, cover what behavior happens automatically when this package is installed and what needs to be manually set up.

As an example, I wrote docs like this for the sway-services project, although they aren't merged yet.

xdbob/sway-services#19

Hi,

Thanks for little gem :)

I tried running this under Sway with the xwayland option set to disable and the script throws the following error:

Failed to connect to X11 display:

I traced back the error in the source code to this hunk of code:

I managed to get the script working under my setup, which you may consider a bit of an edge case, by removing all X11-related code. I would still like to see if we can work around this issue by not throwing an exception if the Xlib library is not installed or there is no X display.

I've researched the DESKTOP_SESSION variable some but am not sure who usually sets. It shows up in recipes like this for starting gnome-keyring-daemon:

if [ -n "$DESKTOP_SESSION" ];then
    eval $(gnome-keyring-daemon --start)
    export SSH_AUTH_SOCK
fi

I think forSway, I think DESKTOP_SESSION is usually set to sway. Should sway-systemd set DESKTO_SESSION or pass it through?

Hey,

Stumbled upon this error while booting up the system and running Standard Notes on sway session exec (autostart):

Jan 18 17:21:55 laptop /usr/libexec/gdm-wayland-session[2593]: ERROR:assign-cgroups:Failed to modify cgroup for Standard Notes
Jan 18 17:21:55 laptop /usr/libexec/gdm-wayland-session[2593]: Traceback (most recent call last):
Jan 18 17:21:55 laptop /usr/libexec/gdm-wayland-session[2593]:   File "/usr/libexec/sway-systemd/assign-cgroups.py", line 243, in _on_new_window
Jan 18 17:21:55 laptop /usr/libexec/gdm-wayland-session[2593]:     await self.assign_scope(app_id, proc)
Jan 18 17:21:55 laptop /usr/libexec/gdm-wayland-session[2593]:   File "/usr/lib/python3.10/site-packages/tenacity/_asyncio.py", line 86, in async_wrapped
Jan 18 17:21:55 laptop /usr/libexec/gdm-wayland-session[2593]:     return await fn(*args, **kwargs)
Jan 18 17:21:55 laptop /usr/libexec/gdm-wayland-session[2593]:   File "/usr/lib/python3.10/site-packages/tenacity/_asyncio.py", line 48, in __call__
Jan 18 17:21:55 laptop /usr/libexec/gdm-wayland-session[2593]:     do = self.iter(retry_state=retry_state)
Jan 18 17:21:55 laptop /usr/libexec/gdm-wayland-session[2593]:   File "/usr/lib/python3.10/site-packages/tenacity/__init__.py", line 360, in iter
Jan 18 17:21:55 laptop /usr/libexec/gdm-wayland-session[2593]:     raise retry_exc.reraise()
Jan 18 17:21:55 laptop /usr/libexec/gdm-wayland-session[2593]:   File "/usr/lib/python3.10/site-packages/tenacity/__init__.py", line 193, in reraise
Jan 18 17:21:55 laptop /usr/libexec/gdm-wayland-session[2593]:     raise self.last_attempt.result()
Jan 18 17:21:55 laptop /usr/libexec/gdm-wayland-session[2593]:   File "/usr/lib64/python3.10/concurrent/futures/_base.py", line 438, in result
Jan 18 17:21:55 laptop /usr/libexec/gdm-wayland-session[2593]:     return self.__get_result()
Jan 18 17:21:55 laptop /usr/libexec/gdm-wayland-session[2593]:   File "/usr/lib64/python3.10/concurrent/futures/_base.py", line 390, in __get_result
Jan 18 17:21:55 laptop /usr/libexec/gdm-wayland-session[2593]:     raise self._exception
Jan 18 17:21:55 laptop /usr/libexec/gdm-wayland-session[2593]:   File "/usr/lib/python3.10/site-packages/tenacity/_asyncio.py", line 51, in __call__
Jan 18 17:21:55 laptop /usr/libexec/gdm-wayland-session[2593]:     result = await fn(*args, **kwargs)
Jan 18 17:21:55 laptop /usr/libexec/gdm-wayland-session[2593]:   File "/usr/libexec/sway-systemd/assign-cgroups.py", line 217, in assign_scope
Jan 18 17:21:55 laptop /usr/libexec/gdm-wayland-session[2593]:     await self._sd_manager.call_start_transient_unit(
Jan 18 17:21:55 laptop /usr/libexec/gdm-wayland-session[2593]:   File "/usr/lib/python3.10/site-packages/dbus_next/aio/proxy_object.py", line 92, in method_fn
Jan 18 17:21:55 laptop /usr/libexec/gdm-wayland-session[2593]:     BaseProxyInterface._check_method_return(msg, intr_method.out_signature)
Jan 18 17:21:55 laptop /usr/libexec/gdm-wayland-session[2593]:   File "/usr/lib/python3.10/site-packages/dbus_next/proxy_object.py", line 62, in _check_method_return
Jan 18 17:21:55 laptop /usr/libexec/gdm-wayland-session[2593]:     raise DBusError._from_message(msg)
Jan 18 17:21:55 laptop /usr/libexec/gdm-wayland-session[2593]: dbus_next.errors.DBusError: Invalid unit name or type.

No issue with Standard Notes observed. It started successfully, so this is probably harmless. Could be related to #8

Environment:
Fedora 35
sway-1.6.1-3.fc35.x86_64
sway-systemd-0.2.1-1.fc35.noarch
standard-notes-3.9.13-linux-x86_64.AppImage
sway config

session.sh script is currently using swaymsg -t subscribe '["shutdown"]' to run tasks on compositor exit. That prevents the script from being reusable in other wayland compositors, e.g. wayfire.

The more portable options are to connect to the wayland socket and wait until it is closed or to lookup the compositor pid by the wayland socket and wait for it's exit with tail --pid.

Hello,
i'm using archlinux and I have installed the sway-systemd aur package.
I have these lines at the bottom of my sway configuration.

exec /usr/lib/sway-systemd/session.sh --with-cleanup
exec /usr/lib/sway-systemd/assign-cgroups.py

Now I try to run flameshot but I get this error

flameshot: error: Unable to detect desktop environment (GNOME? KDE? Sway? ...)
flameshot: error: Hint: try setting the XDG_CURRENT_DESKTOP environment variable.

and this is my systemctl --user show-environment

HOME=/home/gregoire
LANG=en_US.UTF-8
LOGNAME=gregoire
MAIL=/var/spool/mail/gregoire
PATH=/usr/local/bin:/usr/bin
SHELL=/usr/bin/zsh
SYSTEMD_EXEC_PID=878
SYSTEMD_HOME=1
SYSTEMD_HOME_SUSPEND=0
USER=gregoire
XDG_RUNTIME_DIR=/run/user/60177
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/60177/bus
DISPLAY=:0
I3SOCK=/run/user/60177/sway-ipc.60177.887.sock
SWAYSOCK=/run/user/60177/sway-ipc.60177.887.sock
WAYLAND_DISPLAY=wayland-1
XDG_CURRENT_DESKTOP=sway
XDG_SESSION_DESKTOP=sway
XDG_SESSION_TYPE=wayland

Also with
XDG_CURRENT_DESKTOP=sway flameshot it's working

Placeholder task to consider rewriting the script in C++/Rust/Haskell/whatever.

I'm quite comfortable with resource usage of a python script, but if there's someone who aren't it is possible to reimplement the script in a compiled language.