xdbob / sway-services Goto Github PK

Config file is upstream.

I should have a script to migrate configurations

When executing sway-user-service from a shell, /etc/profile has already been sourced and does not need to be sourced again. Although this has limited impact on functionality, it does cause annoyances such as duplicate entries in $PATH.

(I'm comparing my own snowflake service file with others, hopefully dropping the duplicate work there).

As seen in swaywm/sway#5777 there can be problems launching Flatpaks under Sway due to the dbus environment.

To address this, the Arch Linux package for sway ships /etc/sway/config.d/50-systemd-user.conf.

To compare, here's the version shipped by this project:

Current version

# Import variables set-up by sway into the environment and notify systemd that
# sway is ready.
exec systemctl --user import-environment SWAYSOCK \
					 DISPLAY \
					 I3SOCK \
					 WAYLAND_DISPLAY \
					 XCURSOR_SIZE \
					 XCURSOR_THEME \
  && systemd-notify --ready

Arch Linux package version:

#  sway does not set DISPLAY/WAYLAND_DISPLAY in the systemd user environment
# See FS#63021
# Adapted from xorg's 50-systemd-user.sh, which achieves a similar goal.

exec systemctl --user import-environment DISPLAY WAYLAND_DISPLAY SWAYSOCK
exec hash dbus-update-activation-environment 2>/dev/null && \
     dbus-update-activation-environment --systemd DISPLAY WAYLAND_DISPLAY SWAYSOCK

If someone using this project has trouble with Flatpaks, try merging in the approach used by Arch and see it if helps.

emersion/mako#240

A manjaro-sway user reported a really strange issue: when stopping a container using podman stop, sway is being killed. I didn't have a deeper look yet, but could reproduce it quite easily.

https://people.debian.org/~mpitt/systemd.conf-2016-graphical-session.pdf

This issue is for tracking the proposal to add sway-session.target upstream in the Sway project. If that happens, it can be removed here.

swaywm/sway#5622

Calling import-environment without a list of variable names is deprecated.
https://github.com/xdbob/sway-services/blob/master/bin/sway-user-service#L28

graphical session leaves a lot of env variables, they should be cleaned-up at exit (it can make sway fail to restart)

Assuming implement sd-notify status updates when systemd is used by gdamjan · Pull Request #83 · swaywm/swayidle is merged into the swayidle project, we launch the swayidle service with a more precise Type=notify.

It seems that months ago, someone added sway-session.target to sway-contrib.

I tried to install sway-contrib package but it fails because the file already exist and was installed by this package.

pacman -S sway-contrib 

error: failed to commit transaction (conflicting files)
sway-contrib: /usr/lib/systemd/user/sway-session.target exists in filesystem (owned by sway-services-git)
Errors occurred, no packages were upgraded.

I might suggest adapting the .target unit here because it seems to be a custom solution, but I have not fully developed this idea.

In the meantime, is there any workaround?

Thank you for the effort maintaining the package.

Due to the current design services units need After=wayland-session.target in order to avoid racing sway initialization and environment importation...

Current workaround:

$ cat ~/.config/systemd/user/mako.service.d/override.conf
[Unit]
After=wayland-session.target

See #12

I tried to get gnome-keyring as a systemd service with Sway and could not. I believe it was due to making sure that gnome-keyring got launched early and got the environment variable it produces properly exported to other apps.

Eventually I got gnome-keyring working with Ly, but not as a systemd service:

fairyglade/ly#228 (comment)

Shipping a working gnome-keyring intetegration for Sway using systemd would be a helpful reference for how to do it properly.

It was proposed that systemd provide a standardized "wayland-session.target".

systemd/systemd#15180

Instead, the approach implemented was a more general solution of adding ConditionEnvironment= to test environment variables. This was released in systemd v246 which in use now on at least Arch Linux.

Given that, we could adopt the the approach by no longer shipping or referencing a wayland-session.target.

Instead, rely on the standardized graphical-session.target and use ConditionEnvironment=WAYLAND_DISPLAY for services that should only launch under Wayland.

This approach would avoid conflicts with other projects that might otherwise ship a "wayland-session.target" for the same reason this project did.

systemd should not be viewed as a dependency manager but as an event manager (ie: sway should up the *.target witch should not be automatically pulled via dependency).

Also wayland-session*.target will not happen, I should use Condition*=

I don't like it and I would rather have the NotifyAccess set to either main or exec to avoid any user program write access to the service state.