What @bluca says is mostly true and valid. But it is how things should be, not how things actually are, and getting from the latter to the former is easier said than done. E.g. with Xorg it *might* be straightforward to fix the server and simple clients (i.e. those that just call XOpenDisplay). But some clients may wish to do something "fancier", and then there are tools and utilities that may not actually open the display; those all will still expect to find the files under /tmp/.
WRT first at boot vs. replaced later: not quite the same. Programs can and do make sanity checks at startup, refusing to proceed if the owner/permissions are wrong. Not many check at runtime with each usage of the files. Also, this is precisely the purpose of /usr/lib/tmpfiles.d/x11.conf: to ensure correct ownership and permissions; too bad it does not also have rules to prevent removal of the dirs/files. The problem seems to be that in the olden days, /tmp *was* the (world- writable) runtime directory, and that's why it was used as such e.g. by X11 and that legacy practice still continues today (Filesystem Hierarchy Standard v1.0 is from 1994; that is old, but not as old as X11). Also had a thought: I don't know if it was actually codified in any way, but dotfiles directly under /tmp and /var/tmp *may* have been de-facto protected from runtime removal. Either explicitly, or because the cleanup tools (of the time) just did globs of /tmp/* and /var/tmp/* for removal candidates. Adding a tmpfiles rule that achieves this protection might be worth consideration. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xorg in Ubuntu. https://bugs.launchpad.net/bugs/2088268 Title: systemd /tmp cleaning removes files that it shouldn't Status in systemd package in Ubuntu: Confirmed Status in xorg package in Ubuntu: Confirmed Bug description: On Ubuntu 24.04.1, systemd 255.4-1ubuntu8.4, the fix for bug #2019026 causes files under /tmp to be removed if their age is greater than 30 days. However, there are files under /tmp that should not be removed at runtime regardless of their age (whether they belong in that directory at all is a separate question), for example those listed in /usr/lib/tmpfiles.d/x11.conf (I have witnessed the disappearance of X11 lock files, though the sockets are still there; /tmp/.XIM-unix and /tmp/.font-unix have also disappeared). I am not familiar enough with systemd-tmpfiles to figure out whether those files can be properly protected from removal with a tmpfiles.d configuration change, but I do know that the current configuration does not do that. I noticed this problem when a couple of TigerVNC sessions became inaccessible a month after starting them, which turned out to be because the "cached" password file in /tmp/tigervnc.XXXXXX/passwd was removed. This is at least partially a bug in tigervnc, but the problem also affects other critical not-to-be-removed-or-else files under /tmp. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2088268/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
