/tmp/ is world writable, so there is no guarantee that one process will be the first to write to a file anyway. The case of "another process replaced it after deletion" is the same as "another process got there first on boot", and cannot be avoided. Anything using /tmp/ needs to be aware of this, and only use safe and non-guessable subdirectories, for example via mkdtemp, and need to use O_NOFOLLOW and friends when opening, and so on and so forth.
Or just do not use /tmp/ for functionality-critical files, and use RuntimeDirectory= instead which is managed correctly, without any hassle for the program. If any of the above is _really_ not possible, then such package needs to ship a drop-in in /usr/lib/tmpfles.d/ instructing sd-tmpfiles to leave a specific path or pattern alone. -- 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: New Status in xorg package in Ubuntu: New 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
