<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 11, 2023, 19:23 Chandler <<a href="mailto:admin@genome.arizona.edu">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">Mantas Mikulėnas wrote on 4/10/23 10:31 PM:<br>
> The same pam_systemd module registers a "session" with logind (which<br>
> triggers the creation of runtime directory as well as the startup of<br>
> user@<uid>.service; note: /not/ user@<username>)<br>
hmmm... it's a bit ambiguous since we use LDAP too. There, "uid" is a<br>
user name, while "uidNumber" would be the equivalent to $UID variable in<br>
bash, and "UID" printed by loginctl.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">The rest of the system doesn't really care or change its terminology even if you use LDAP; here it's still an UID in the regular Unix sense ("uid_t" or "struct pwent->pw_uid") where it's always an integer.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
`systemctl start user@<username>.service` does something though, since<br>
`status` shows it's running and everything, e.g.:<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Systemd resolves user names when provided via User=, which is where the instance name goes in this case, but that's not the intended usage of user@.service.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
* user@userName.service - User Manager for UID userName<br>
Loaded: loaded (/usr/lib/systemd/system/user@.service; static; vendor<br>
preset: disabled)<br>
Active: active (running) since Mon 2023-04-10 17:05:53 MST; 15h ago<br>
Main PID: 1635797 (systemd)<br>
Status: "Startup finished in 408ms."<br>
Tasks: 155<br>
Memory: 102.1M<br>
CGroup: /user.slice/user-userName.slice/user@userName.service<br>
|-dbus.service<br>
| `-1635943 /usr/bin/dbus-daemon ...<br>
|-docker.service<br>
| |-1635811 rootlesskit ...<br>
| |-1635831 /proc/self/exe ...<br>
| |-1635857 slirp4netns ...<br>
| |-1635868 dockerd<br>
| `-1635915 containerd --config /run/user/$UID/docker ...<br>
`-init.scope<br>
|-1635797 /usr/lib/systemd/systemd --user<br>
`-1635800 (sd-pam)<br>
<br>
what have I done?? I guess I should stop the service?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">You should just stop it, or it'll result in a bit of a mess when both user@fooName and user@1000 are started for the same account.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> and sets<br>
> XDG_RUNTIME_DIR after the session has been registered. Check whether<br>
> your tty or display is shown in the `loginctl` session list.<br>
Well, our Session, UID, and user names are shown, but the SEAT and TTY<br>
columns are blank for everyone...<br>
<br>
> Note that logind does not allow registering sessions from within another<br>
> session, so tools like `su` won't be able to do that (except for some<br>
> situations where they can but you wouldn't want them to) – only a fresh<br>
> login gets you a session. So usually step 1 is to not use `su` or `sudo`<br>
> here – run `machinectl shell foo@` if you need a shell for a local user.<br>
Gotcha, thanks, I didn't know that or about machinectl!<br>
<br>
So, I tried stopping user@userName.service since that seemed incorrect<br>
to start it manually from root. The /run/user/$UID dir went away. I<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">In recent systemd versions it *shouldn't break anything*, at the very least, as the runtime directory is now created via regular dependencies (i.e. through user-runtime-dir@$UID.service). Still, it should probably be left to logind (using the linger flag if necessary), i.e. it should not be *necessary* to start it manually.</div><div dir="auto"><br></div><div dir="auto">In older versions (without user-runtime-dir@), this would have failed as there was nothing that would create the runtime directory on demand (with logind itself doing it as part of the session registration).</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
tried `machinectl shell userName@` which was successful but there is<br>
still no /run/user/$UID dir and `systemctl --user` returning the same<br>
bus connection failure message from before...<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">That still sounds like a PAM issue; machined does set up a PAM session for `machinectl shell`, so I'm guessing pam_systemd is completely gone from /etc/pam.d (wherever your distro usually has it).</div><div dir="auto"><br></div><div dir="auto">(Maybe a pam_succeed_if has been told to skip too many modules for a certain user, for example?)</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I tried checking `systemctl status user@$UID.service` for another<br>
account that is not logged in at all or listed in `loginctl` output<br>
(let's say user2), and reported it was loaded but inactive, and no<br>
/run/user/$UID dir for user2 either. Then after `machinectl shell<br>
user2@` and checking user@$UID.service status again, it is active and<br>
running, and /run/user/$UID is created and `systemctl --user status`<br>
works too.<br>
<br>
So there is something quirky with the other user's account preventing<br>
proper implementation/startup of systemd user instance... any other ideas?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Did that user already have an active logind session at that time? Normally user@ is started either when the user's session count goes from 0 to non-0 (or on boot if linger is enabled); but if something has manually stopped it, I don't think logind will try to restart it?</div><div dir="auto"><br></div><div dir="auto">Check the system logs.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>