On Tue, Apr 11, 2023, 19:23 Chandler <ad...@genome.arizona.edu> 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.
>
