Session registered with login should be registered with TTY=wayland not shell TTY that is currently asserted

No, TTY should be the controlling TTY for any physical session. The logind session type1 should be "wayland"2 (only used to change the behavior of IdleHint when the string is either "x11", "wayland" or "mir"), which is set dynamically by libseat3 if you set XDG_SESSION_TYPE before starting sway.

Maybe try setting XDG_SESSION_TYPE=wayland before starting sway and see if that does the trick? That's what I do in my sway-run, and what's mentioned in the wiki4.

ok i think im missing something i followed your suggestion of a shell wrapper and my local shells in sway show the correct XDG_SESSION_TYPE=wayland

however when i run loginctl show-session x i still see a TTY=ttyX

i tried this with both gtkgreet wlgreet and tuigreet

gino

however when i run loginctl show-session x i still see a TTY=ttyX

That's also correct as I mentioned in the previous comment - the logind "TTY" session variable must be set to the TTY for the VT you used to login.

It's "Type" that should be set to "wayland".

Here is my current run-sway wrapper that i'm using

#!/bin/sh

# Session
eval $(/usr/lib/systemd/user-environment-generators/30-systemd-environment-d-generator)
export XDG_SESSION_TYPE=wayland
export XDG_SESSION_DESKTOP=sway
export XDG_CURRENT_DESKTOP=sway

systemd-cat --identifier=sway sway $@

despite this i am still getting Type=tty

loginctl show-session 34
Id=34
User=1000
Name=grey
Timestamp=Wed 2021-10-20 21:09:54 PDT
TimestampMonotonic=52962780670
VTNr=5
Seat=seat0
TTY=tty5
Remote=no
Service=login
Scope=session-34.scope
Leader=62570
Audit=34
Type=tty
Class=user
Active=yes
State=active
IdleHint=yes
IdleSinceHint=1634455784414391
IdleSinceHintMonotonic=0
LockedHint=no

also swayidle returns the following error on start

Failed to send sleep inhibit signal: Permission denied
Failed to send SetIdleHint signal: Idle hint control is not supported on non-graphical sessions.

Thanks for taking the time to help me through this.

I'm having the same problem. Logind session has Type=tty and swayidle cannot set IdleHint. I have XDG_SESSION_TYPE=wayland.

I'm observing the same issue on a Debian system with greetd and tuigreet. Setting XDG_SESSION_TYPE=wayland in a wrapper script is not sufficient on my machine. The "Failed to send SetIdleHint signal: Idle hint control is not supported on non-graphical sessions." messages are logged, too.

After a bit of research, it appears to me that pam_systemd.so is where XDG_SESSION_TYPE is evaluated. Other LMs than greetd might do that as well, I've really not checked that, but Sway itself does not, I think. The pam module has a debug parameter. So after configuring

/etc/pam.d/common-session
session optional pam_systemd.so debug=true

I get messages like this:
Aug 05 19:11:02 HOSTNAME greetd[224305]: pam_systemd(login:session): Asking logind to create session: uid=1000 pid=224305 service=login type=tty class=user desktop= seat=seat0 vtnr=7 tty=tty7 display= remote=no remote_user= remote_host=

I've tried using
command = "env XDG_SESSION_TYPE=wayland tuigreet --remember --remember-user-session --issue --sessions /usr/local/share/wayland-sessions:/usr/local/share/xsessions:/usr/share/wayland-sessions:/usr/share/xsessions"
in config.toml, but that doesn't work. It's not a huge surprise, because my user might not like greeter's env variables. ;)

Configuring this in /etc/pam.d/common-session, just for testing, works for me:
session optional pam_systemd.so debug=true type=wayland

Aug 05 19:36:28 HOSTNAME greetd[254943]: pam_systemd(login:session): Asking logind to create session: uid=1000 pid=254943 service=login type=wayland class=user desktop= seat=seat0 vtnr=7 tty=tty7 display= remote=no remote_user= remote_host=

But that's not ideal, of course, if I want to login on tty, or login to the machine via ssh.

I'm not sure if there is any other pam hook that could be used. I should think for those distros where it does work, there's another invocation of pam_systemd.so. But when common-session is the only place that applies it, setting the environment variable in the wrapper script or .desktop file is too late, because at that point the session is already started and the module has done its magic.

The problem lies between the two points you've provided debug for. The expected flow is:

1. Create logind session which by default ends up being of the TTY type.
2. Your target application starts, which end up calling the SetType dbus endpoint to change the type appropriately. libseat will take care of this if XDG_SESSION_TYPE is set to something if the logind backend is used for seat management (i.e., not using seatd, seatd-launch or "builtin").
3. Your compositor tries to call SetIdleHint.

You have debug on 1 and 3, but the issue must lie with 2. The question we need to answer is why does SetType either not work or not get called in the first place. One way is to use sudo busctl monitor on a different TTY to look for the SetType call and return value.

SetType was introduced in systemd v246, and should be in Debian Bullseye from what I can tell.

Thanks for the additional explanations which now solved the issue for me.

SetType did not get called at all in my case. Turns out, seatd was running as well as logind. I'm honestly unsure what led to that configuration, and I've not seen libseat log output and at 4am I'm too tired to figure out where to look, but I assume libseat defaulted to seatd before logind, quick glance at the source doesn't at least seem to contradict that assumption. ;)

Once I disabled seatd or added LIBSEAT_BACKEND=logind in my sway launch script, SetType is called and the session type is wayland.

thanks all, adding export LIBSEAT_BACKEND=logind to my run-sway script fixed my issue

Looking at the packages, I think I installed seatd due to a misunderstanding of the building dependencies of wlroots/sway, so that was probably my fault.

I'm also inclined to think that seatd and systemd-logind running at the same time is a subtle trap, so the Debian packages could potentially deal with this situation with a warning or some such. Time's always short, but if I ever see a chance for a package bug report I'll consider that.

End-users do not need to run both - seatd is for those who do not have or do not wish to use logind, with libseat supporting both.

They do sometimes co-exist, especially for developers as seatd is far easier to use than logind when working over SSH (common when writing/debugging display servers), in CI and similar. Regarding changes, note that being packaged and being enabled differs, so maybe all that is needed is a documentation update.

I agree with ~rovertmueller2 i think this issue should be clarified downstream, for example, Gentoo, currently installs the full seatd when you install sway, it doesn't specify in any manor that if systemd-logind is running / exists don't start seatd, i'll file a bug report request more options be added to install the libseat components without installing seatd be an option

Hi, gentoo packager of seatd here.

They do sometimes co-exist, especially for developers as seatd is far easier to use than logind when working over SSH (common when writing/debugging display servers), in CI and similar. Regarding changes, note that being packaged and being enabled differs, so maybe all that is needed is a documentation update.

So, just to be sure, this is purely a runtime issue and there can be setups with systemd-logind / elogind being installed but not launched?

Then, I guess contrib/systemd/seatd.service should be updated to have Conflicts=systemd-logind,elogind (not tested, only checked systemd.unit(5)).

Which sadly doesn't seems to be an option in OpenRC[1], but I guess elogind could refuse to start when seatd is started and vice-versa.

1: https://github.com/OpenRC/openrc/issues/486

On Wed, Aug 17 2022 at 03:01:06 PM +00:00:00, Haelwenn (lanodan) Monnier outgoing@sr.ht wrote:

So, just to be sure, this is purely a runtime issue and there can be setups with systemd-logind / elogind being installed but not launched?

This particular issue? Yes. Having (e)logind, not starting it, starting seatd instead and expecting (e)logind behaviors.

Then, I guess contrib/systemd/seatd.service should be updated to have Conflicts=systemd-logind,elogind (not tested, only checked systemd.unit(5)).

No, I wouldn't see that as the conclusion. One shouldn't start random services just because they're included in packages - even when they do need to run, starting them isn't always the right thing to do.

Whatever setup documentation/guide was followed might need to clarify that (e)logind should be started if one is using that. If one is installing a system entirely on their own, the manpages of (e)logind should be followed.

Which sadly doesn't seems to be an option in OpenRC[1], but I guess elogind could refuse to start when seatd is started and vice-versa.

seatd and (e)logind are used in tandem in certain setups. It is very common for both to be used during development of display servers on (e)logind based systems as seatd makes it trivial to start a compositor over SSH (one cannot easily debug a display server on the same machine one works on). (e)logind requires considerable fiddling to do the same.

Thanks for the clarifications, sent https://github.com/gentoo/gentoo/pull/27235 to address this problem.

[2022-09-13 09:14:30+0000] ~kennylevinsen:

On Wed, Aug 17 2022 at 03:01:06 PM +00:00:00, Haelwenn (lanodan) Monnier outgoing@sr.ht wrote:

Then, I guess contrib/systemd/seatd.service should be updated to have Conflicts=systemd-logind,elogind (not tested, only checked systemd.unit(5)).

No, I wouldn't see that as the conclusion. One shouldn't start random services just because they're included in packages - even when they do need to run, starting them isn't always the right thing to do.

Whatever setup documentation/guide was followed might need to clarify that (e)logind should be started if one is using that. If one is installing a system entirely on their own, the manpages of (e)logind should be followed.

Well it was more like a case of a bad default[^1] and bad assumption from a user, there isn't a setup documentation/guide other than the manpages and README.md from the seatd project.

[^1]: seatd enabled by default, while most users probably already have (e)logind enabled

On Tue, Sep 13 2022 at 10:56:56 AM +00:00:00, Haelwenn (lanodan) Monnier outgoing@sr.ht wrote:

there isn't a setup documentation/guide other than the manpages and README.md from the seatd project.

If you are using (e)logind, the applicable documentation would be that from systemd or elogind. It's strictly speaking not seatd's job to document how to use other projects in its place.

[^1]: seatd enabled by default, while most users probably already have (e)logind enabled

Talk to your package managers. If your distribution is init-system agnostic, it might also want to offer seatd as alternative to elogind when not using systemd. libseat is often packaged separately from seatd, so that packages can depend on the library without needing to installing the daemon. If your distribution likes to enable services by default for convenience, then this might be a better option than breaking pattern for seatd.

[2022-09-13 11:47:30+0000] ~kennylevinsen:

On Tue, Sep 13 2022 at 10:56:56 AM +00:00:00, Haelwenn (lanodan) Monnier outgoing@sr.ht wrote:

there isn't a setup documentation/guide other than the manpages and README.md from the seatd project.

If you are using (e)logind, the applicable documentation would be that from systemd or elogind. It's strictly speaking not seatd's job to document how to use other projects in its place.

[^1]: seatd enabled by default, while most users probably already have (e)logind enabled

Talk to your package managers. If your distribution is init-system agnostic, it might also want to offer seatd as alternative to elogind when not using systemd. libseat is often packaged separately from seatd, so that packages can depend on the library without needing to installing the daemon.

As I said earlier, I'm the package maintainer for seatd for gentoo, which is init-system agnostic. I effectively just missed that (e)logind was set as a system default for desktop users, so seatd being built by default didn't made sense.

And there isn't install-time package splits in gentoo, usually USE-flags are just used to disable/enable features instead.

If your distribution likes to enable services by default for convenience, then this might be a better option than breaking pattern for seatd.

That's not the case and I don't think it will be at any point, doesn't prevents users from being trigger-happy on enabling it though.

On Tue, Sep 13 2022 at 12:12:20 PM +00:00:00, Haelwenn (lanodan) Monnier outgoing@sr.ht wrote:

As I said earlier, I'm the package maintainer for seatd for gentoo

Ah yeah, sorry about that, was mixing up who I was responding to.

That's not the case and I don't think it will be at any point, doesn't prevents users from being trigger-happy on enabling it though.

Not much we can do about users being blindly trigger-happy. We do have an FAQ/Wiki that could mention such things (https://man.sr.ht/~kennylevinsen/seatd/), but it only helps those that read it. Same goes for the seatd and elogind pages, which could refer to each other.