~robertmueller2


#27 greetd doesn't properly handle logind TTY variable 2 years ago

Comment by ~robertmueller2 on ~kennylevinsen/greetd

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.

#27 greetd doesn't properly handle logind TTY variable 2 years ago

Comment by ~robertmueller2 on ~kennylevinsen/greetd

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.

#27 greetd doesn't properly handle logind TTY variable 2 years ago

Comment by ~robertmueller2 on ~kennylevinsen/greetd

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.