On Sat, Sep 9, 2023, at 11:11, Josselin Poiret via Bug reports for GNU Guix wrote: > I'd still like feedback from actual users of wlgreet, as I have not used > it myself. I do believe the only way it could work is because something > takes care of creating the runtime directory.
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: https://paste.sr.ht/~droyo/6cd5f6c1cb12220d10dbcbe0f92f317dfdc88aee 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: https://git.sr.ht/~kennylevinsen/seatd-docs/tree/master/item/index.md#xdg_runtime_dir-not-set 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 https://guix.gnu.org/manual/en/html_node/Base-Services.html#index-greetd_002dwlgreet_002dsway_002dsession 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
