This is my conclusion as well. I ran into this issue today when trying to
setup a minimal install with sway. I had to switch from seatd to elogind.
Here's my working config:
Here's my understanding of the issue;
* greetd runs as root, but when the user switches to a vt, it forks a
child process to run the default_session command (agreety, wlgreet,
etc). This process runs as the `(default-session-user config)`
(default "greeter".
* sway requires XDG_RUNTIME_DIR to exist, but there is nothing creating
XDG_RUNTIME_DIR on behalf of "greeter", so it repeatedly crashes
until herd disables the `term-ttyX` service corresponding to the
wlgreet terminal.
* When using elogind, this is taken care of for "greeter" by the
pam_elogind pam module, which is added to all pam configs, including
greetd's, by the `elogin-service-type` service. On other distros,
pam_systemd performs the same task.
This issue is summarized by the author of seatd here:
The solution prescribed is to create the rundir from a script on startup
or with a pam module. I was curious why the existing `pam_mount(5)`
module in greetd's existing PAM configuration did not handle creation
for the "greeter" user as well. The pam_mount configuration linked to
/etc/security/greetd_pam_mount.conf.xml does not discriminate against
this user.
I set `debug=1` in /etc/security/greetd_pam_mount.conf.xml and restarted
the system. Here's the `pam_mount` logs for the "greeter" user's session:
greetd: (pam_mount.c:568): pam_mount 2.18: entering session stage
greetd: (pam_mount.c:629): no volumes to mount
greetd: command: '/gnu/store/18wjrghh95hy8l4nmr22lpsjgjpdqbax-greetd-pam-mount-2.18/sbin/pmvarrun' '-u' 'greeter' '-o' '1'
greetd: (pam_mount.c:441): pmvarrun says login count is 2
greetd: (pam_mount.c:660): done opening session (ret=0)
greetd: (pam_mount.c:706): received order to close things
greetd: (pam_mount.c:709): No volumes to umount
And for my session (after logging into a separate vt running agreety):
greetd: (pam_mount.c:568): pam_mount 2.18: entering session stage
greetd: (mount.c:781): Could not get realpath of /run/user/1000: No such file or directory
greetd: (mount.c:251): Mount info: globalconf, user=droyo <volume fstype="tmpfs" server="(null)" path="none" mountpoint="/run/user/1000" cipher="(null)" fskeypath="(null)" fskeycipher="(null)" fskeyhash="(null)" options="noexec,nosuid,nodev,size=1g,mode=0700,uid=1000,gid=998" /> fstab=0 ssh=0
greetd: (mount.c:305): mkmountpoint: checking /run
greetd: (mount.c:305): mkmountpoint: checking /run/user
greetd: (mount.c:345): mkdir[0] /run/user
greetd: (mount.c:351): chown /run/user -> 1000:998
greetd: (mount.c:305): mkmountpoint: checking /run/user/1000
greetd: (mount.c:329): mkdir[1000] /run/user/1000
greetd: (mount.c:660): Password will be sent to helper as-is.
greetd: command: '/gnu/store/w62dxljn51hcrszyxjb1dffhbvrl8iqm-util-linux-2.37.4/bin/mount' '-onoexec,nosuid,nodev,size=1g,mode=0700,uid=1000,gid=998' '-ttmpfs' 'none' '/run/user/1000'
I could not find any obvious problem reading pam_mount.c, so I read the
pam_mount.conf file a little closer and found the issue:
<volume sgrp="users" fstype="tmpfs" ...
Per pam_mount.conf(5), sgrp restricts pam_mount's activity to users in
the "users" group. So adding "users" to `greeter-supplementary-groups`
resolves the issue.
Sorry for being long-winded. I thought maybe including the steps I took
would help others stuck in similar issues troubleshoot. As far as fixing
this one, should we update the example in
or is it better to force a fix and modify pam_mount or make the
greetd-wlgreet-* sessions enforce some check on group membership?
Another thing, the /run/user created by pam_mount is owned by the
first session's user (greeter:greeter), while with pam_elogind it's owned
by root:root. It doesn't seem to cause a problem, but I just thought I'd
call that out.
David
