g-w linux: should perform a user login (XDG_RUNTIME_DIR not set)

[aerickson]

Describe the bug

Debugging Wayland issues, we notice that the XDG_RUNTIME_DIR env var (https://wiki.alpinelinux.org/wiki/Wayland) is not set. It's critical for Wayland functioning. It's normally set by pam_systemd when a user login is performed.

It looks like in

taskcluster/workers/generic-worker/multiuser_posix.go

Lines 136 to 139 in 5f78921

	// Defaults that can be overwritten by task payload env
	taskEnv["HOME"] = filepath.Join(gwruntime.UserHomeDirectoriesParent(), taskContext.User.Name)
	taskEnv["PATH"] = "/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin"
	taskEnv["USER"] = taskContext.User.Name

we execute via os/exec's Command (https://pkg.go.dev/os/exec#Command) which seems to not perform a user login.

To Reproduce

Run a task on a Wayland worker in community of firefoxci (gecko-t/t-linux-2204-wayland-exp-a2), the XDG_RUNTIME_DIR will be unset. This causes issues.

Expected behavior
XDG_RUNTIME_DIR is set to a valid path (e.g. from a working laptop running Wayland 22.04: XDG_RUNTIME_DIR=/run/user/1001).

Taskcluster version
g-w multi: [taskcluster 2024-04-19T05:32:12.111Z] "version": "64.2.0"

Screenshots

Additional context

[petemoore]

I'm not sure this is a bug. Generic Worker is agnostic to the choice of display server protocol, it depends what is set up on the host. Generic Worker is bound to the Gnome Desktop Manager, but does not assume Wayland is in use. I feel like the right place to set this might be in the task, or in Generic Worker configuration:

          runAfterUserCreation              A string, that if non-empty, will be treated as a
                                            command to be executed as the newly generated task
                                            user, after the user has been created, the machine
                                            has rebooted and the user has logged in, but before
                                            a task is run as that user. This is a way to
                                            provide generic user initialisation logic that
                                            should apply to all generated users (and thus all
                                            tasks) and be run as the task user itself. This
                                            option does *not* support running a command as
                                            Administrator. Furthermore, even if
                                            runTasksAsCurrentUser is true, the script will still
                                            be executed as the task user, rather than the
                                            current user (that runs the generic-worker process).

This would allow setting it at a worker pool level, which seems appropriate because not all worker pools might want to use Wayland.

Update: actually, this might not work, because the env var wouldn't carry over to the task commands. But if you want the task commands to have extra env variables set when running bash, maybe you can update e.g. /etc/bashrc on the host? Would some variation of this work?

[aerickson]

I think the ask here is that g-w executes a user/login session (vs the current non-login session) and then PAM will take care of the required env variables (not that g-w starts figuring out what subsystem is in use).

[petemoore]

Generic Worker just executes the commands in the task payload, so if a login shell is required, and currently a non-login shell is being used by the task, then the current bash task command can have -l added to it, to make it a login shell.

[aerickson]

Using bash -l is undesirable for a few reasons:

• non-standard: It's not how a normal user session works and we aim to be as close to a real user session as possible.
• maintenance burden: It's burdensome to have every test run bash -l vs bash. Tests are defined all over the codebase and authors will struggle to know why this is needed.
  • bash -l alone didn't work for setting XDG_RUNTIME_DIR (it's not a full login session in PAM's eyes?). Alissy also had to set XDG_RUNTIME_DIR in /etc/profile to get things working.

[lissyx]

At some point from my testing perspective we can live with just setting the env var. I'll see if I can draft a PR.