/run/user/$UID is no longer created when user@ is masked

[Earnestly]

• Arch Linux
• systemd 239

Currently I mask user@1000 (not user@) as I can't make use of systemd --user and it helps to prevent a lot of the services it might start which I control elsewhere.

Since version 239 after logging in, that while XDG_RUNTIME_DIR is set, /run/user/1000 has not being created causing issues with local services I run such as pulseaudio.

To work around this issue I'm using sudo install -dm0700 -o "$USER" /run/user/"$UID" to manually create this directory which seems to be fine.

I believe this regression was initiated by #7339 where perhaps it should have used 2841493 with the requirements on user-runtime-dir@%j.service instead.

[poettering]

@keszybz ?

[keszybz]

Yeah, that's something I didn't take into account when writing this. I guess it's a use case we should support. I see two options:

• make logind also start user-runtime-dir@UID.service. When systemd-user@UID.service is started in the usual fashion, this will be a noop.
• add a user-session@.target, that'd pull in both units, and then have logind start that. The advantage would be that it'd be more generic.

Either option should be fairly easy to execute, I'm just not sure what the best approach is.

[sourcejedi]

I think having logind literally just start user-runtime-dir@UID.service wouldn't work, because the service has StopWhenUnneeded=yes. Maybe that settles the choice?

The name user-session@.target seems a bit weird to me thinking about sessions (and if the user is lingering, there may be no sessions). Maybe user@.target instead?

[jnpkrn]

I am also affected since v239 and Fedora, at least with something related.

When I log in within VT, I see that user@UID.service failed with

Failed to fully start up daemon: Permission denied

(the reason is not very apparent, sadly)

So to workaround that, I need, as root, create respective /run/user/UID, like OP,
and start user@UID.service anew. Only then, I'll get the user services like
PulseAudio running.

Also, I used to start the window manager using dbus-launch PROG, which
doesn't work for me even then, but that may have another cause, and I can still
run PROG directly with success. But that also used to work like a charm with v238.

[poettering]

Fix is waiting in #9824.