Re: [EXT]Re: systemd user instance not working in only one account, XDG_RUNTIME_DIR not being set

[Chandler <admin@xxxxxxxxxxxxxxxxxx>]

Mantas Mikulėnas wrote on 4/10/23 10:31 PM:
> 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: /not/ user@<username>)
hmmm... it's a bit ambiguous since we use LDAP too.  There, "uid" is a
user name, while "uidNumber" would be the equivalent to $UID variable in
bash, and "UID" printed by loginctl.

`systemctl start user@<username>.service` does something though, since
`status` shows it's running and everything, e.g.:

* user@userName.service - User Manager for UID userName
   Loaded: loaded (/usr/lib/systemd/system/user@.service; static; vendor
preset: disabled)
   Active: active (running) since Mon 2023-04-10 17:05:53 MST; 15h ago
 Main PID: 1635797 (systemd)
   Status: "Startup finished in 408ms."
    Tasks: 155
   Memory: 102.1M
   CGroup: /user.slice/user-userName.slice/user@userName.service
           |-dbus.service
           | `-1635943 /usr/bin/dbus-daemon ...
           |-docker.service
           | |-1635811 rootlesskit ...
           | |-1635831 /proc/self/exe ...
           | |-1635857 slirp4netns ...
           | |-1635868 dockerd
           | `-1635915 containerd --config /run/user/$UID/docker ...
           `-init.scope
             |-1635797 /usr/lib/systemd/systemd --user
             `-1635800 (sd-pam)

what have I done??  I guess I should stop the service?

> and sets
> XDG_RUNTIME_DIR after the session has been registered. Check whether
> your tty or display is shown in the `loginctl` session list.
Well, our Session, UID, and user names are shown, but the SEAT and TTY
columns are blank for everyone...

> 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.
Gotcha, thanks, I didn't know that or about machinectl!

So, I tried stopping user@userName.service since that seemed incorrect
to start it manually from root.  The /run/user/$UID dir went away.  I
tried `machinectl shell userName@` which was successful but there is
still no /run/user/$UID dir and `systemctl --user` returning the same
bus connection failure message from before...

I tried checking `systemctl status user@$UID.service` for another
account that is not logged in at all or listed in `loginctl` output
(let's say user2), and reported it was loaded but inactive, and no
/run/user/$UID dir for user2 either.  Then after `machinectl shell
user2@` and checking user@$UID.service status again, it is active and
running, and /run/user/$UID is created and `systemctl --user status`
works too.

So there is something quirky with the other user's account preventing
proper implementation/startup of systemd user instance... any other ideas?

Thanks