~robertmueller2


#27 greetd doesn't properly handle logind TTY variable 5 days 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.