Chris's Wiki :: blog/linux/UserRuntimeDirectories Commentshttps://utcc.utoronto.ca/~cks/space/blog/linux/UserRuntimeDirectories?atomcommentsDWiki2021-12-16T08:01:13ZRecent comments in Chris's Wiki :: blog/linux/UserRuntimeDirectories.From 193.219.181.242 on /blog/linux/UserRuntimeDirectoriestag:CSpace:blog/linux/UserRuntimeDirectories:743431a5849188ae1340811b0900b5b3ed70d979From 193.219.181.242<div class="wikitext"><p>One of the reasons each UID gets their own tmpfs mount (instead of sharing the parent /run tmpfs) is so that they could have individual <code>size=</code> limits. Apparently the limit is configurable through <code>logind.conf</code>. Originally the runtime directory was supposed to be the per-user equivalent of <code>/var/run</code> – i.e. to hold sockets, pipes, flag files, and other such IPC-related things that occupy little to no space (definitely not for log files; that should go to ~/.cache if not /dev/null).</p>
<p>Aside from cleaning up /tmp (similar to the system-wide migration of /var/run/foo, /tmp/foo, /dev/.foo, /dev/shm/.foo, /lib/init/rw/foo… towards a neat and tidy /run), predictable naming to reduce the reliance on environment variables was one big reason; for example, D-Bus client libraries have been patched so that they'll look for <code>/run/user/<uid>/bus</code> <em>by default</em> if the corresponding environment variable is not set. There were patches to do the same for libX11 as well, but they fizzled out.</p>
<p>(GnuPG with its gpg-agent has taken this to an extreme and made it incredibly difficult to <em>not</em> use the runtime directory for gpg-agent sockets.)</p>
<p>The <code>doc</code> FUSE mount is something to do with Flatpak's "Documents portal" – if I remember correctly, it's how sandboxed apps are given access to individual files (the "Open" dialog runs on the host and lets you select the file which is then exposed via FUSE to guest).</p>
<p>(The <code>gvfs</code> mount just exposes GNOME's GVFS userspace filesystem connections, so that e.g. <code>smb://</code> or <code>sftp://</code> "mounts" can be usable to non-GTK apps. KDE now has an equivalent as well, probably at <code>kio-fuse</code>.)</p>
<p>IIRC, runtime dir creation was moved out to <code>user-runtime-dir@</code> service so that <code>user@.service</code> would behave nicely if someone started it manually and not through pam_systemd. (Previously the only way to get a runtime dir was to have a logind session, or use its linger mechanism.)</p>
<p>I'm not sure how all of this works on non-systemd distros, although I think at least <em>elogind</em> will just create the runtime dir in the same way (i.e. <code>pam_elogind</code>), and I've seen a <code>pam_xdg</code> module somewhere around that's supposed to do the same in a more lightweight way.</p>
<p>In general, though, if the runtime dir isn't present, some programs will fall back to the user's cache directory (<code>~/.cache</code>), some will fall back to <code>/tmp</code>, some functionality won't exist at all, some will revert to the older implementation (e.g. the "user bus" is implemented via <code>systemd --user</code> having dbus.service, so if there's no systemd then there's no per-user dbus.service and you just get the traditional behavior of running <code>dbus-launch</code> and creating <code>/tmp/dbus-XXXXXX</code> sockets). Out of curiosity I checked what the Wayland client libraries do, and it seems they'll insist on <code>WAYLAND_DISPLAY</code> pointing to an absolute path in that situation.</p>
</div>2021-12-16T08:01:13Z