5 ms·
I've tried to use Sway a number of times, and the biggest reason I keep bouncing off it is environment variables. There's a bunch of environment variables I wa
by thristian 4y ago
I've tried to use Sway a number of times, and the biggest reason I keep bouncing off it is environment variables.
There's a bunch of environment variables I want set for every process in my desktop session, from basic things like $EDITOR and $LD_LIBRARY_PATH to more complex things like $MOZ_USE_XINPUT2 or $SSH_AUTH_SOCK. When I use i3 under X11, gdm runs my ~/.profile script so I get all my standard login environment variables, then it runs ~/.xsession so I get all my GUI-specific settings. There's also some integration with systemd so that the SSH agent can set $SSH_AUTH_SOCK and have it show up in my terminals.
With Wayland/Sway, none of this works. gdm does not execute ~/.profile, and there's no equivalent to ~/.xsession. Something starts a user-level systemd instance, but its environment variables aren't synced to the compositor, and the compositor doesn't use it to start apps, so $SSH_AUTH_SOCK isn't available in anything I care about.
Having an SSH agent seems like such a basic feature, but it doesn't work for me and I can't even imagine where I'd begin to look for the problem, or for documentation to learn more about it.
- noahtallen 4y agoDefinitely agree. It took several days to figure out the exact environment variables needed to get basic applications working and scaling properly. For example, if you want “click link and open it in default browser” to work in, say, Slack, you need environment variables to get it working. And since (like you say) basic profiles are not executed on startup, it’s very difficult to fix anything. I completely disagree with the Sway author’s approach to go batteries excluded for the project. It means that next to nothing works out of the box, and that you either have to put in hours of work to fix undocumented things, or rely on a distro to package everything exactly right. And there really aren’t any distros packaging Sway right now. Sway would benefit from integrating more of these things out of the box and it should rely much less on end-user configuration and other software to accomplish basic desktop behavior. One excellent example is that you need a separate Lock Screen app like swaylock to lock your computer. And since you’re in charge of configuring all its settings, it’s difficult to know if you’ve done something insecure. Otherwise, I really enjoyed using it.
- rogers18445 4y agoIt seems to me that sway is intended for power users, people who know exactly what is going on with their linux from boot to window manager, and thus have no difficulty configuring whatever they desire. If sway adopts opinionated defaults it will mess with people who don't care for those defaults. Perhaps there is a way to do it such that opinionated defaults immediately turn off in the presence of configuration but as far as I can see there is no interest in this.
- rogers18445 4y agoWhen you 'exec sway' it inherits the tty env vars... So just stuff your vars into whatever .profile the tty loads when you login after boot. This has never been a problem I spent any amount of time on. If you are doing something magical like auto starting sway or something, then you need to make sure that a .profile is loaded by whatever is starting sway if it doesn't inherit a .profile.
- mst 4y agoI have pretty much always been in the "log in on console, then startx" camp but I suspect you and I are a vanishingly small minority these days.
- noobermin 4y agoIn addition to the reply, he mentions gdm so he likely doesn't login from the console. This is a bit extreme but one day they might (for security reasons) remove that too.
- cesarb 4y ago> With Wayland/Sway, none of this works. gdm does not execute ~/.profile, and there's no equivalent to ~/.xsession. Something starts a user-level systemd instance, but its environment variables aren't synced to the compositor, and the compositor doesn't use it to start apps, so $SSH_AUTH_SOCK isn't available in anything I care about. This probably won't help you, since you say the compositor isn't using the user-level systemd instance to start apps, but in case it helps someone else: I recently faced a similar problem at work (I needed to set the DOCKER environment variable so that unit tests running directly from the IDE could find the podman socket from the user-level podman.socket systemd unit), and solved it by creating a file under ~/.config/environment.d (https://www.freedesktop.org/software/systemd/man/environment.d.html https://www.freedesktop.org/software/systemd/man/environment...).
- cycomanic 4y agoThis is not really a wayland or sway problem, but really a systemd problem. It's really annoying because the documentation around this is very scattered and contradictory. The advice used to be that you should use pam user environment (~/.environment and you need to edit pam configuration on some distributions to allow user environments). However, IIRC there are some possible security implications around this so this has been deprecated. I think you are now supposed to use systemd user variables (or so). I'm not on my computer right now so can't look it up, but hopefully that gives you enough Google keywords to set things up. It seems like the main developers behind systemd and several of the other fundamental layers of the system stack only use gnome/KDE and assume everyone else is. So some things become quite frustrating to set up for regular users.
- thristian 4y agoYeah, I can create files in ~/.config/environment.d/ to set some environment variables. My problems are that (a) that syntax only allows very simple variable assignments, not complex things like "run ssh-agent and add the environment variables it prints to stdout" and (b) those environment variables aren't available to the Wayland compositor or applications it launches.
- shmerl 4y agoSomehow all that works fine in KDE with Wayland. So may be it's a problem with Sway. See also: https://invent.kde.org/plasma/plasma-workspace/-/wikis/Plasma-and-the-systemd-boot https://invent.kde.org/plasma/plasma-workspace/-/wikis/Plasm...
- argulane 4y agoUnder GDM you can use systemd environment.d(5)[1] to configure those variables. I have some examples in my dotfiles[2]. Your Sway configuration also has to inject it's own environment variables to systemd session like is documented here[3]. Arch Linux does that in `/etc/sway/config.d/50-systemd-user.conf`[4] If you really want to run some shell scripts before sway then you have to create a new desktop file under `/usr/share/wayland-sessions/` that calls your script that setups environment and does `exec sway`[5] [1]: https://man.archlinux.org/man/environment.d.5 https://man.archlinux.org/man/environment.d.5 [2]: https://github.com/artizirk/dotfiles/tree/master/.config/environment.d https://github.com/artizirk/dotfiles/tree/master/.config/env... [3]: https://wiki.gnome.org/Initiatives/Wayland/SessionStart https://wiki.gnome.org/Initiatives/Wayland/SessionStart [4]: https://github.com/archlinux/svntogit-community/blob/packages/sway/trunk/50-systemd-user.conf https://github.com/archlinux/svntogit-community/blob/package... [5]: https://github.com/swaywm/sway/issues/100 https://github.com/swaywm/sway/issues/100
- epakai 4y agoI settled on pam_env and ~/.pam_environment for handling these. Required a small change to pam config to load it by default, but it felt like a sane solution at the time.
- blibble 4y agodon't use a display manager, use regular login on /dev/tty1 and have your .profile start sway (with whatever environment you want)
- RMPR 4y agoSame here. I also use i3 in a non-standard way: in KDE but with i3 instead of Kwin, and it has been the dream setup for me navigation wise. I wished I could somehow do the same with Sway under Wayland, But that doesn't seem to be supported.
- thristian 4y agoYeah, I've got a lovely GNOME+i3 setup that I really like. There doesn't seem to be an equivalent for Sway, but the GNOME services get more memory-hungry over time so I'm always looking to see about Sway becoming more usable.