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

[Mantas Mikulėnas]

On Tue, Apr 11, 2023, 19:23 Chandler <admin at 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 at userName.service - User Manager for UID userName
>    Loaded: loaded (/usr/lib/systemd/system/user at .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 at 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 at fooName and user at 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 at 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.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20230411/df0a8891/attachment.htm>