<div dir="ltr"><div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 11, 2023, 03:41 Chandler <<a href="mailto:admin@genome.arizona.edu" target="_blank">admin@genome.arizona.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">systemd has been working great here, system-wide as well as in all user<br>
instances except one.  I'm not exactly sure what all the steps are in<br>
the process to get a systemd user instance running.  The directory<br>
/run/user/$UID was not being created, though.<br>
<br>
I made some progress by running `systemctl start<br>
user@<username>.service` and the /run/user/$UID was created.<br>
<br>
`systemctl --user status` returns `Failed to connect to bus: No such<br>
file or directory`.  XDG_RUNTIME_DIR is not being set, but a command<br>
like `XDG_RUNTIME_DIR=/run/user/$UID systemctl --user status` runs<br>
successfully, so I think it's down to this last piece.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto"></div><div>The same pam_systemd module registers a "session" with logind (which triggers the creation of runtime directory as well as the startup of user@<uid>.service; note: <i>not</i> user@<username>) and sets XDG_RUNTIME_DIR after the session has been registered. Check whether your tty or display is shown in the `loginctl` session list.<br></div><div><br></div><div>Note that logind does not allow registering sessions from within another session, so tools like `su` won't be able to do that (except for some situations where they can but you wouldn't want them to) – only a fresh login gets you a session. So usually step 1 is to not use `su` or `sudo` here – run `machinectl shell foo@` if you need a shell for a local user.<br></div><div><br></div><div><br></div></div>
</div>