Include a systemd.service file

[WhyNotHugo]

I'm wondering if it would be possible to include a systemd.service(5) file with sway.

The wiki gives clear instructions on how to copy-paste one to run sway as a systemd service, but including one with sway itself might make this more "standard", facilitating setup for many users (and making setups a bit more homogeneous, except for those that actually want to tinker extra).

Installing something like this into /usr/lib/systemd/user/sway.service should do:

[Unit]
Description=sway - SirCmpwn's Wayland window manager
Documentation=man:sway(5)
BindsTo=graphical-session.target
Wants=graphical-session-pre.target
After=graphical-session-pre.target

[Service]
Type=simple
EnvironmentFile=-%h/.config/sway/env
ExecStart=/usr/bin/sway
Restart=on-failure
RestartSec=1
TimeoutStopSec=10

Also, for apps that rely on sway, it makes providing their own systemd service file easier, since they'd have an explicit service to rely on.

[emersion]

I personally wouldn't be against having it in contrib/systemd/. Should definitely not be officially maintained though.

[ddevault]

NACK, because people are going to use it anyway and are inevitably going to file bugs which are caused by it. This already happens. Not going to block this if I'm outnumbered, though.

[emersion]

TBH, I'm not sure what to do about bugs for contrib/ material anyway. We could decide to never accept bug reports, only accept patches for these.

[WhyNotHugo]

It's hard to think of bugs that would come up exclusively due to running as a systemd service. Bug report rules could include "try running this without systemd before reporting bug" though, just to rule those out.

I also don't mind being tagged in bugs that are a direct result of this, I've been messing around with systemd user services for years.

[kennylevinsen]

Using systemd user services like this introduces quite a few areas of surprise.

Just looking at the referenced service file, this will not yield stable results if depended upon. Dependent services will launch immediately after systemd forks off sway, and will race with sway initialization and your config posting WAYLAND_DISPLAY to systemd. exit will also just lead to sway restarting after 1 second, rather than logging you out or dropping your to a shell. Your session itself will also effectively be a blocking wait, in order to keep the session open, as your actual session (sway) no longer dictates the session lifetime.

A solution to utilizing user services that I personally find to be more correct would just be a sway.target started at the bottom of your config after sending your environment to systemd. This is simpler, easy to debug from inside a session, does not change how sway is started, and is also roughly equivalent to what the GNOME team did with their user service implementation if you simplify it a bit.

[ascent12]

Trying to start Wayland compositors from systemd services come with all sorts of weirdness and potential session management issues, and no solution I've ever seen really is truly portable/general for everybody. I don't think this is something I want upstream.

I basically agree with what @kennylevinsen said.

For starting Wayland compositors automatically, I think an extremely basic display manager (even if it has no GUI and just launches it unconditionally) would work better. systemd/logind is much more geared to handling display managers.

[WhyNotHugo]

Just looking at the referenced service file, this will not yield stable results if depended upon. Dependent services will launch immediately after systemd forks off sway, and will race with sway initialization and your config posting WAYLAND_DISPLAY to systemd.

You're very right. I'd never though of this, but you're very right. 😞

A solution to utilizing user services that I personally find to be more correct would just be a sway.target started at the bottom of your config after sending your environment to systemd.

I wonder if such a target file could be included with systemd though. Again, just to standardise what target other software will rely on.

Again, I just find it annoying that every user has to copy-paste files from different source to get things up and running, and since everyone makes it slightly different, the heterogeneity in setups makes all forms of support and sharing so hard.

As an alternative, sway could use sd_notify to notify systemd when it's done starting up. Since there' already reliance on systemd-logind, I don't think this would add any extra build dependency.

I think an extremely basic display manager (even if it has no GUI and just launches it unconditionally) would work better.

I've read a lot about display managers, but I can't figure out what they bring to the table. If one has multiple DEs, they offer a list to pick one, but if I just use sway, it seems like a pointless one-button screen that just adds startup time.

[emersion]

As an alternative, sway could use sd_notify to notify systemd when it's done starting up. Since there' already reliance on systemd-logind, I don't think this would add any extra build dependency.

-1, logind is unrelated to running Sway as a systemd service.

[WhyNotHugo]

I meant to say that this would not introduce a new dependency.

[rumpelsepp]

As an alternative, sway could use sd_notify to notify systemd when it's done starting up. Since there' already reliance on systemd-logind, I don't think this would add any extra build dependency.

IIRC there is a command (aka binary) to notify readiness. This could live at the end of the sway config.
update: systemd-notify

[kennylevinsen]

I've read a lot about display managers, but I can't figure out what they bring to the table. If one has multiple DEs, they offer a list to pick one, but if I just use sway, it seems like a pointless one-button screen that just adds startup time.

Login managers are just the unit that opens a PAM session, setuid's to the target user and launches your application of choice—any interactive multi-user machine will have one. If you log into a console, it's usually login(1) which executes $SHELL, presented by agetty(8). Other login managers allow you to—sometimes interactively—pick an alternative shell such as sway, which is logically what you're trying to achieve.

You don't need the complexity of GDM to do that. You have options like ly, or, to make a shameless plug, greetd.

As an alternative, sway could use sd_notify to notify systemd when it's done starting up. Since there' already reliance on systemd-logind, I don't think this would add any extra build dependency.

-1, this can be done by those wanting it in the config file. It's already troublesome that sway has to know about logind.

I don't see there being an issue where people has to "copy-paste files from different sources". Sway starts and works OOTB, and getting additional services started in tandem is very easy—much easier than through user services. Non-bug support problems are usually related to things like not having the default terminal, trying weird custom configurations, or the occasional individual troubled by trying to run sway itself as a user service. :)

[travankor]

or, to make a shameless plug, greetd.

Unrelated, greetd seems very neat. I would like to see this packaged for linux distros.

Should gtkgreet get packaged as well (no release tags yet)? wlgreet and dlm seem like they are more for experimental purposes than for distros (ie: Will they be maintained long-term?).

[kennylevinsen]

@travankor It's a bit off-topic here—the mailing list and support channel are the appropriate places to go. Quick answers: greetd, gtkgreet and wlgreet are packaged in AUR, greetd and gtkgreet is tagged, wlgreet is seeing new interest, dlm is mostly just a PoC. The idea is that it's simple to make greeters, so maybe others' will show up.

[cypa]

btw, which sway problems do you want to solve with systemd?

[ikalnytskyi]

I personally want to see Sway logs in journalctl, and I don't know how to hook it up without running Sway as systemd service. Does anybody know by any chance? 🤔

[kennylevinsen]

systemd-cat --identifier=IDENTIFIER COMMAND.

[maximbaz]

@ikalnytskyi I haven't tried personally but maybe something like this would work?

/usr/bin/sway 2>&1 | /usr/bin/logger

[WhyNotHugo]

For simplicity's sake, I just run sway as a systemd --user service.

I also run all my other background services this way (fcitx, waybar, deluged, etc). I'm gotten used to having a service manager to start/stop/monitor these services rather than have them all just run loose.

I guess running sway the same way is also a habit since that's how I'd run i3 too.

[rumpelsepp]

systemd-cat --identifier=IDENTIFIER COMMAND.

This works like a charm:

#
# ~/.bashrc
#

# If not running interactively, don't do anything
[[ $- != *i* ]] && return

# If running from tty1 start sway
if [[ "$(tty)" == "/dev/tty1" ]]; then
    # https://github.com/systemd/systemd/issues/14489
    export XDG_SESSION_TYPE=wayland
    exec systemd-cat -t sway sway
fi

[WhyNotHugo]

I've been thinking about it, and running i3 as a systemd service made more sense -- I could stop/restart it sometimes, while keeping Xorg and all other apps alive.

In sway's case, restarting it does not makes sense; that kills everything. That's analogous to restarting Xorg, not just i3. And I already have a hotkey to reload sway in-place anyway.

I therefore think it doesn't make as much sense to run sway as a systemd service. I guess it's hard to fully understand when migrating from Xorg+i3. Intuitively, one want to change the overall setup as least as possible, but that's not necessarily a good idea here.

I therefore don't think including the service file makes sense any more, and am inclined to close this request. I will try to reflect these thoughts on the wiki though; others have supported this request, and maybe the same insight is useful to them...?

That aside, I do think sway should include a sway-session.target file, to ease the configuration described here. If all users are expected to place a file with static content in a fixed location, it might as well be packaged in.

This would also allow tools like waybar to include a systemd file that just depends on that target too, as well as standardise setups a bit.

---

Edit: Yes, systemd-cat works like a charm for the logging side ✨
I'll mention this in the wiki too.

[blaggacao]

btw, which sway problems do you want to solve with systemd?

Maybe I'm completely out of band (and terribly missed something).

I'm attempting to bring some order into my environment setup which occasionally brakes all the time. Therefore, I figured, environment.d is a neat "solution" to that problem: the lookup order combined with the name itself tells me everything I need to know, in case I had forgotten it.

Now there is systemctl --user show-environment, but I haven't seen anyone mentioning using this anywhere (on the whole swaywm community) so I wonder if this is legit? - there is #3109 to that means-end, as well.

But based on #3109 (comment)

Why do you need to source /etc/profile?

I figured, enabled by environment.d for the usual path things, the answer should be: I don't.
Basically, I want to get those ~/.cargo/bin, ... available @dmenu.

Any insight? Is systemctl --user show-environment already there, at all, when the login manager forks sway? Are they racing?

[kennylevinsen]

environment.d is a systemd thing, only loaded for systemd units. Neither login managers themselves nor PAM interact with this.

I recommend against usage of such pointless "environment loading" mechanisms (e.g. pam_env, environment.d, ...). They are unnecessary, complex, inflexible, and attempting to use them usually brings nothing but pain.

Usage of a wrapper script (e.g. "sway-run"), or even .profile, is a much cleaner and ultimately superior solution to any "environment loader". The wrapper script approach:

1. Permits you to have a sway specific environment (XDG_CURRENT_DESKTOP=sway, wayland activation stuff, ...);
2. Can source from whatever (source .profile, have them both source e.g. ~/.config/env, whatever you want);
3. Has no dependencies; and
4. Works with anything capable of starting sway.

Can't really beat that.

[blaggacao]

Thanks @kennylevinsen !

This is what I finally ended up with in sway-run.sh to mimic behaviour of environment.d - so that I occasionally can start a gnome shell, if need be and have the same (sane) environment - I deleted all damn cluttered profile* files. I's kind of a compromise and does have a dependency, but I assume it to be compatible with all major systemd based distributions in wayland or X (at least eventually).

#!/bin/bash
...
# Environment
while read -r l; do
    eval export $l
done < <(/usr/lib/systemd/user-environment-generators/30-systemd-environment-d-generator)
...

Would I be encouraged to put this in the wiki section?

For avoidance of doubt, I still use the other recommended parts for sway-run.sh and don't try to do that through environment.d - for more obvious reasons:

# Session
export XDG_SESSION_TYPE=wayland
export XDG_SESSION_DESKTOP=sway
export XDG_CURRENT_DESKTOP=sway

source /usr/local/bin/wayland_enablement.sh

PS: If I'd had used /profile, I'd had to do an obscure wrapper to launch sway from a login shell. Which isn't clean neither.

[Gigadoc2]

environment.d is a systemd thing, only loaded for systemd units. Neither login managers themselves nor PAM interact with this.

That is not entirely true, GDM for example requests the current environment from the systemd user daemon at login and uses that as a clean (it does not pass along environment variables it itself has been started with) environment for the launched session. Well, except for PATH, which I've filed a bug about, but there is some friction to get that solved.

I recommend against usage of such pointless "environment loading" mechanisms (e.g. pam_env, environment.d, ...). They are unnecessary, complex, inflexible, and attempting to use them usually brings nothing but pain.

I would say that this is subjective. pam_env certainly has the problem of evaluating user-generated files as root, but environment.d (or the other environment generators for that matter) explicitly has not. It is also not unnecessary (in general), as this presents an unified way to set environment variables for user services and the session. It is certainly not more complex than shell scripts, and since generators can also be shell scripts it can not be less flexible than them either.
Of course, this all depends on whether you want to use systemd user services, but I certainly don't want to just launch my applications from sway to just have them "float around" in my session. Sway does not want to be a process manager, which is completely fine, but then I am going to use a different process manager instead.

I don't think that sway should include a service file right now, as the whole "run your session as user services" thing is still quite new and there needs some standardization (for target names and such) before anyone should ship official services (and I know that sway never will, but still). But, running a sway session with the environment from environment.d is certainly possible, with or without having sway itself be a user serivce.

[kennylevinsen]

I don't think this issue is the correct forum to continue environment loading discussions. The issue was only about inclusion of a systemd user service in the repo.

If people want to bend over backwards to use an environment loader that (as per its own man page) is only meant for systemd user services, they can of course do that, but they'll be on their own. Systemd user services being young has nothing to do with them being poorly suited for the task.

GDM's use of a wrapper around your session to load environment (again bending over backwards to load due to GNOME being infatuated with user services to the point of abusing the functionality) just cements wrappers as the correct way of inserting your environment.

Making systemd parse your file, import it, have you request it over dbus, and then you reparse it to be setenv compatible is just a waste of time if you're already have a wrapper script that does not need any of those steps. This is especially true if you want user services in a graphical environment, as that requires you to overwrite the systemd user environment anyway, making the entire exercise for naught.

[Gigadoc2]

I don't think this issue is the correct forum to continue environment loading discussions. The issue was only about inclusion of a systemd user service in the repo.

You are right about that, but since the last posts in this issue kind of convey the incorrect message that using the systemd environment is not possible, or not intended from the systemd side (I am fully aware that for the sway project this is not the intended usage), I wanted to correct that (as I am using sway in the exact way which was said to be not possible). It looks like my version of the manpage is different from yours, but don't take it from me, the official systemd documentation mentions running applications as services.

Now obviously this is not supported or encouraged by the sway project in any way, and I am not here to discuss that. I just want to state that, inofficially, this is possible, and while the sway project does not support this approach, the systemd project has no qualms with it (as of now at least).

[kennylevinsen]

I wanted to correct that (as I am using sway in the exact way which was said to be not possible). It looks like my version of the manpage is different from yours, but don't take it from me, the official systemd documentation mentions running applications as services.

You completely misread.

I said that environment.d(5) is only for services started by the systemd user instance (see here and here - apologies for XML, but that's systemd manpage sources).

I did not say that you cannot run arbitrary applications as user services - you definitely can (except for the session-leader process). I have, however, explained why I find systemd user services to be unsuitable for starting a user shell (e.g. sway), and that I find the use systemd user services just to read environment.d to be a bit of a pointless exercise. Same with using "show-environment" to extract the systemd environment.

I'm happy to entertain further arbitrary discussions on IRC, but unless there is something to add about sway, there is no need to spam this issue any further.

[blaggacao]

I'll take the liberty and drag my "solution" to the wiki pages.

[emersion]

Related i3 discussion: i3/i3#5186