Arch Linux

https://github.com/swaywm/sway/wiki/Systemd-integration

is their suggestion for configuration; I'm not sure importing the entire environment is necessarily correct and I think something like

exec systemctl --user import-environment DISPLAY; exec systemctl --user import-environment WAYLAND_DISPLAY

would be better (for the contents of the file /etc/sway/conf.d/10-systemd.conf).

Thanks for reporting. Is this also an issue with the latest version of Sway, version 1.2?

Yes, upstream doesn't want to include systemd-specific options in their default configuration.

I'll look into adding systemd configuration to the sway package, unless someone are completely against this.

>I've discussed this with upstream and they think it should be in user configuration

Yes. We don't want to have any configuration file specific to an init daemon in particular.

>is their suggestion for configuration

No, wiki pages are not "upstream recommendation", they are user-contributed guides. Added a note to clarify that.

>I think that this behavior should be default in the same way that X provides this functionality with a configuration file.

What does X11 do?

> I'm not sure importing the entire environment is necessarily correct

Some other env variables should probably be imported, like SWAYSOCK and XCURSOR_*.

To be honest I'm not sure whether this is a good idea. If no Sway service file is shipped, what's the point of importing the environment?

Not importing the environment unfortunately causes some services that require a graphical connection (e.g. gpg-agent, for opening the pin entry program) to fail. In the case of the gpg-agent, of course, with terrible error messages, because it's gpg.

I had remembered incorrectly; there's a file /etc/X11/xinit/xinitrc.d/50-systemd-user.sh that's owned by systemd that sets DISPLAY for user systemd, but I thought it would be a bit strange to ship systemd with separate configuration files for each of the compositors. Given that systemd is pretty built into Arch now, I think it would be sensible for the Arch packages to include init scripts in the compositor packages to set the environment variables, though that's obviously entirely up to the maintainers.

$ cat /etc/X11/xinit/xinitrc.d/50-systemd-user.sh
#!/bin/sh

systemctl --user import-environment DISPLAY XAUTHORITY

if command -v dbus-update-activation-environment >/dev/null 2>&1; then
dbus-update-activation-environment DISPLAY XAUTHORITY
fi


Xorg is a pretty standard display server, with exactly one place where this stuff is "expected" to be stored. The example xinitrc makes sure to source the "well-known" files here, and https://wiki.archlinux.org/index.php/Xinit#xinitrc has a note that any custom xinitrc should at least implement that sourcing.

For Xorg, the DISPLAY and XAUTHORITY files are the minimum which any applications needing to see the display server absolutely must have access to.

@emersion,

This is not about shipping a systemd service with sway, there is no systemd service for Xorg either. :p

However, in order for systemd services to see your manually started Xorg or sway, it is necessary to tell them where to find it.

A possibly related issue which I was pinged for, today, is https://github.com/keybase/client/issues/19614

> I think it would be sensible for the Arch packages to include init scripts in the compositor packages to set the environment variables, though that's obviously entirely up to the maintainers.

I forgot about user services like gpg-agent.

Well, I guess it's up to the maintainers as you said.

I updated the sway package to include /etc/sway/conf.d/10-systemd.conf that exports the relevant environment variables.

Please confirm that it is working as expected.

@xyproto Shouldn't your 10-systemd.conf file be located in the default /etc/sway/config.d directory, the content of which is included at the end of the default /etc/sway/config file?
Also, from what I understand, such configuration files are not expected to be shell scripts, so you should probably follow the Sway wiki page mentioned above and use Sway's exec command.

Edit: In addition, any reason you're not importing XCURSOR_THEME too?
Plus, as dbus-update-activation-environment is shipped by the dbus package which is itself required by systemd, why not use only this command with the `--systemd` option?

Thanks, I'll look more carefully into this and fix it.

Considering this is implemented via https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/sway&id=e9718f1d739cc3bfef6794c33424a60dd1b145ed should this be closed?

No, this ticket is not about starting sway using systemd services.

It's about having sway export its environment variables into systemd for use by services that may want to communicate with the sway display server.

...

The more appropriate commit would be this: https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/sway&id=25fb6171a749a99ba9d29aa838f575f14937cab1

But, what does this even do? It's a shell script installed to /etc/sway/conf.d/10-systemd.conf, does this directory execute shell scripts? According to  FS#65267 , no it does not.

Sorry Eli, that's the commit I meant. My apologies.

These do seem to be exported:

[~]$ echo $WAYLAND_DISPLAY
wayland-0
[~]$ echo $SWAYSOCK
/run/user/1000/sway-ipc.1000.1630.sock
[~]$ echo $XCURSOR_SIZE
24

I'm not sure I agree with the inclusion of this file in the first place - it's not "correct" in the sense that it creates custom behavior specific to Arch and is not required for the software to function. It's a nicety that should either be included upstream or added by the user.

Gah, I feel stupid. This file is supposed to be setting the systemd user environment. Derp.

In any case, it does appear that this file does *not* work, as systemctl --user show-environment does not show any of these variables. I think this should be removed.

You mean just like the xorg one in /etc/X11/xinit/xinitrc.d/50-systemd-user.sh ?

Which isn't required for xorg to function either, but is required for some software, such as the gpg-agent, to function in combination with X.

Aside: the variable surely exist in your terminal, but I'd be more interested if e.g. this listed the variables in question

systemd-run --user /usr/bin/printenv
journalctl --user

EDIT: err yeah, that

Ah, I found out that this file is installed in /etc/sway/conf.d, and *not* the /etc/sway/config.d dir that is referenced in the stock configuration. That would explain why it's not run.

So this software has been working despite a broken stock configuration for a while now.

Quoting https://wiki.archlinux.org/index.php/Arch_Linux:

>[...] Arch ships the configuration files provided by upstream with changes limited to distribution-specific issues like adjusting the system file paths.

I can see the usefulness of automatically setting this parsing up, but it feels to be a violation of Arch's principles of simplicity.

Pulling myself back brings these questions up:

* Is there any situation in which a user will not want these imported in a systemd-centric distribution like Arch?
* Will this complicate bug reports upstream?
* Will this create unexpected behavior?

I argue that the answer is "no" to all three of those, so it seems logical to keep this inclusion, especially since the precedence was set with X11.

I'll move /etc/sway/conf.d to /etc/sway/config.d and then close this task.

Yeah, I agree it's not clear-cut. On the other hand, this could be viewed as just setting up a default config for system integration. Fortunately it's not my job to make the final call. :D

Hi all,

sway 1:1.4-2 has been uploaded to [community-staging]. This package includes this commit:

https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/sway&id=92829209ed44389b31243b73a13f3dd8edf28178

Please test and give feedback if desired.

Thanks!

Hmm, what's the intention of switching from command -v to hash? The former will print output (stdout) when the command exists, the latter will print output (stderr) when the command doesn't exist. Either way, this should be properly handled IMO.

I assume sway's exec command runs the arguments in an sh shell? hash ... 2>/dev/null should work fine.

the command -v output was silenced with '>/dev/null 2>&1', so the addition of '-v' was perplexing to me.

I had switched to hash because I foolishly thought that it only returned 0 or nonzero without any output and it made for a shorter line. Thanks for catching that I didn't silence stderr. I've pushed sway 1:1.4-3 to include that.

Edit: Ah, I see that the '-v' flag is necessary for command to function. I'll leave hash in as they're both POSIX tools and I'm used to using it. :)

Ah, in this case command -v doesn't mean "-v for verbose", it means "display information about the detected command, instead of actually executing the detected command".

command -v is the POSIX way to check if a command exists and show you where it is. hash is also POSIX, but its only guarantee is that hashing a command will return successfully with empty stdout if the command exists, and running hash without options will display (to stdout) implementation-defined user-readable output about the pathnames for commands that have been previously looked up and found. You're relying on the first detail, which is entirely reasonable as you don't actually care what the filepath is.

Thanks for the update!
What about the second part of my comment above, regarding XCURSOR_THEME and dbus-update-activation-environment's `--systemd` option?

@thithib, thanks for the poke.

I'm of the opinion that theming options need not be imported at all - adding this custom behavior irks me enough, but the justification is reasonable enough that I'm willing to add it to a default system config to provide functionality required for other Arch packages to work. I'd advise customizing a user config. Regarding the --systemd flag, it seems reasonable to include, so I've done that.

I've pushed 1.4-4 to [community-staging] to reflect these changes

@ainola I agree about the theming options.

As for dbus-update-activation-environment's `--systemd` option, the thing is that according to the manual, it seems redundant with `systemctl --user import-environment`. My "experiments" confirm that and I've been running without the systemctl call for a long time now, thus I would remove it. But I see you're testing for the existence of the dbus-update-activation-environment command, and I'm curious: can a user be legitimately running an Arch system without dbus, as it is required by systemd itself?

I would guess that the separate command for dbus is because of the alternative implementations available - I'm not experienced in any of the alternatives and didn't want to rock the boat so I copied the xorg package like the vacuous follower that I am.

Another reason for us not to ship things like this. :P

It still seems to be causing problems.

If I run commands from 50-systemd-user.conf I'm getting this error:

dbus-update-activation-environment: warning: error sending to systemd: org.freedesktop.DBus.Error.Spawn.ChildExited: Process org.freedesktop.systemd1 exited with status 1