On Tue, Apr 11, 2023, 19:23 Chandler <admin@xxxxxxxxxxxxxxxxxx> wrote:
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.
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.
`systemctl start user@<username>.service` does something though, since
`status` shows it's running and everything, e.g.:
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.
* 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?
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.
> 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
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.
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).
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...
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).
(Maybe a pam_succeed_if has been told to skip too many modules for a certain user, for example?)
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?
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?
Check the system logs.
