Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Project wiki example systemd user unit does not work #4157

Closed
cowile opened this issue May 16, 2019 · 17 comments

Comments

@cowile
Copy link

commented May 16, 2019

I have been trying to start sway as a systemd user unit using the example on the project wiki. Sway does not start at all.

  • ~/.config/systemd/user/sway.service:
[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
ExecStart=/usr/bin/sway
  • Sway Version:
{
   "human_readable": "1.0",
   "variant": "sway",
   "major": 1,
   "minor": 0,
   "patch": 0,
   "loaded_config_file_name": "\/home\/$USER\/.config\/sway\/config"
 }
  • journalctl --user -u sway:
May 16 11:52:31 carbon-x1 systemd[963]: Started sway - SirCmpwn's Wayland window manager.
May 16 11:52:31 carbon-x1 sway[27079]: 2019-05-16 11:52:31 - [wlroots-0.5.0/backend/wayland/backend.c:199] Could not connect to remote display: No such file or directory
May 16 11:52:31 carbon-x1 sway[27079]: 2019-05-16 11:52:31 - [wlroots-0.5.0/backend/x11/backend.c:185] Failed to open X connection
May 16 11:52:31 carbon-x1 sway[27079]: 2019-05-16 11:52:31 - [wlroots-0.5.0/backend/session/logind.c:576] Session '893' isn't a graphical session (type: 'tty')
May 16 11:52:31 carbon-x1 sway[27079]: 2019-05-16 11:52:31 - [wlroots-0.5.0/backend/session/direct-ipc.c:35] Do not have CAP_SYS_ADMIN; cannot become DRM master
May 16 11:52:31 carbon-x1 sway[27079]: 2019-05-16 11:52:31 - [wlroots-0.5.0/backend/session/session.c:96] Failed to load session backend
May 16 11:52:31 carbon-x1 sway[27079]: 2019-05-16 11:52:31 - [wlroots-0.5.0/backend/backend.c:282] Failed to start a DRM session
May 16 11:52:31 carbon-x1 sway[27079]: 2019-05-16 11:52:31 - [sway-1.0/sway/server.c:46] Unable to create backend
May 16 11:52:31 carbon-x1 systemd[963]: sway.service: Main process exited, code=exited, status=1/FAILURE
May 16 11:52:31 carbon-x1 systemd[963]: sway.service: Failed with result 'exit-code'.
@ddevault

This comment has been minimized.

Copy link
Member

commented May 16, 2019

The wiki content is unsupported - if you figure it out, update the wiki. Good luck.

@ddevault ddevault closed this May 16, 2019

@boucman

This comment has been minimized.

Copy link

commented May 21, 2019

it's sway that exits immediately. Not the unit that is not started... It seems to complain that it does not have CAP_SYS_ADMIN
It makes sense that a normal user does not have cap_sys_admin, but I'm not sure why it's needed, nor how it is not needed when launching sway from the shell...

@ascent12

This comment has been minimized.

Copy link
Member

commented May 21, 2019

A wayland compositor needs elevated permissions to access /dev/input/* and CAP_SYS_ADMIN to use a certain privileged operation on GPUs which is required for VT switching to work properly.
If you're logged into a normal systemd login session, we will use logind which handles all of these extra permissions for us, as allows us to run as a completely normal user. However, systemd units don't run inside of your normal login session, so logind isn't going to work. We have to do it the manual way, which means extra permissions (usually suid root).

It's really an upstream systemd issue and there isn't anything we can do about it. I don't know if it's possible to write a unit file which will work robustly in all situations with a Wayland compositor. Another solution is for someone to write a minimal display manager that works with Wayland compositors. I don't think most sway users are going to want to pull in GDM.

@cowile

This comment has been minimized.

Copy link
Author

commented May 21, 2019

Thanks for weighing in. This isn't urgent, but it is something of an annoyance I have been looking at on and off. I found some email tidbits that suggest it should be possible to start a wayland-based WM this way, but not enough to synthesize a working setup.

@rindeal

This comment has been minimized.

Copy link

commented May 22, 2019

This isn't systemd issue at all, but logind/wlroots issue. It's the same problem that Xorg devs debated 5 years ago in this thread.

I managed to run sway from a systemd --user process by trivially patching wlroots, but not without some annoyances.

Major problem in making all this work is deprecated logind "session-guessing" behaviour as documented here. Sadly, the APIs are still not gone even after 2 years passed.

I'll do some more patching and will see where that leads to.

@mnussbaum

This comment has been minimized.

Copy link

commented May 22, 2019

I think you need to set the XDG_SESSION_TYPE environment variable to a value of wayland such that it's set for your sway systemd unit. I have sway running as a systemd user unit and I have the session type set in /etc/environment, but I'm sure there are other places it could be set too. Some docs about that env var can be found here.

Wlroots looks to see if that session type is set here, and when it doesn't find a match it's logging Session '893' isn't a graphical session (type: 'tty') as you see in your log output.

@rindeal

This comment has been minimized.

Copy link

commented May 22, 2019

I think you need to set the XDG_SESSION_TYPE environment variable to a value of wayland such that it's set for your sway systemd unit. I have sway running as a systemd user unit and I have the session type set in /etc/environment, but I'm sure there are other places it could be set too. Some docs about that env var can be found here.

Wlroots looks to see if that session type is set here, and when it doesn't find a match it's logging Session '893' isn't a graphical session (type: 'tty') as you see in your log output.

This works around the problem just halfway. You will get sway running, but it defies the purpose of logind's session type parameter (all sessions will be 'wayland' including tty, ssh, ...) and doesn't solve the issue with the inability to change VTs.

@boucman

This comment has been minimized.

Copy link

commented May 22, 2019

is it simply a normal environment variable ? if yes you can set it with Environment= in the service itself, right ?

@ascent12

This comment has been minimized.

Copy link
Member

commented May 22, 2019

@rindeal What types of changes to wlroots are you talking about?

@rindeal

This comment has been minimized.

Copy link

commented May 22, 2019

is it simply a normal environment variable ? if yes you can set it with Environment= in the service itself, right ?

The variable is read by pam_systemd not sway, as such it must be set before you even log in.

@rindeal

This comment has been minimized.

Copy link

commented May 22, 2019

@rindeal What types of changes to wlroots are you talking about?

Specifying the ID of a session that should be taken over. The current systemd user unit support code introduced in swaywm/wlroots@c138da2 assumes that user is logging in using GDM or something similar.

@ascent12

This comment has been minimized.

Copy link
Member

commented May 22, 2019

I wouldn't be opposed to an environment variable doing that. We already have several similar sorts of things for overriding a bunch of our autodetection logic.

@emersion

This comment has been minimized.

Copy link
Member

commented May 22, 2019

Isn't there a "standard" env variable for this?

@ascent12

This comment has been minimized.

Copy link
Member

commented May 22, 2019

I don't think so? If there already is something established, then sure, use that.
Something along the lines of

WLR_LOGIND_SESSION=/org/freedesktop/login1/session/_32 sway
@rindeal

This comment has been minimized.

Copy link

commented May 22, 2019

Isn't there a "standard" env variable for this?

There is, check out this code.

@joshuarli

This comment has been minimized.

Copy link

commented May 22, 2019

@cowile is your user in the input and video groups?

@cowile

This comment has been minimized.

Copy link
Author

commented May 25, 2019

@joshuarli I tried that on your suggestion and got the exact same errors.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
8 participants
You can’t perform that action at this time.