When a "systemd --user" instance is spawned by user@.service, it gets /run as its runtime directory (i. e. %t inside of units resolves to /run) instead of /run/user/$UID, as it was with v204.
Hm, I can't confirm this. I tried: [Service] ExecStart=/usr/bin/sleep 100 Environment=TDIR=%t and /proc/<pid>/environ contains TDIR=/run/user/1005 as expected. Can you show where exactly are you getting %t pointing to /run?
Here it is. I've tried a simple unit (linked to default.target.wants): [Unit] Description=Unit that shows XDG_RUNTIME_DIR=%t [Service] Type=oneshot ExecStart=/bin/false In logs it appeared as "Unit that shows XDG_RUNTIME_DIR=/run". I'll attach logs shortly. And here is a bit of research. I found that there is no /etc/pam.d/systemd-shared, although it is mentioned in user@.service (PAMName=systemd-shared). I've tried symlinking system-login -> systemd-shared, and that solved (well... worked around) the bug.
Created attachment 84716 [details] Log for systemd --user's PID (initially).
Created attachment 84717 [details] Log for systemd --user's PID (after symlinking the PAM config).
It is confusing and annoying that systemd throws errors and doesn't work properly without a configuration file. Even though user sessions are not ready for general consumption, we should not be shipping with a configuration that throws errors by default. To some extent this is a distribution problem, since PAM setup varies widely, but hopefully we can find something that works most of the time.
Should now work with http://cgit.freedesktop.org/systemd/systemd/commit/?id=5c390a4.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.