On 2020-07-10 11:49:45 +0200, Richard Brown wrote:
We recently moved MicroOS and Kubic to use tmpfs for /tmp instead of writing files there to disk.
This means files written to /tmp as never written to disk and so dissapear on reboot.
This was for a number of reasons, including
- Reducing wear on SSDs/SD card storage - Using less disk space and being more tidy generally - Being more like many other Distro's and Unixes including Debian, Arch, Fedora, Solaris, etc - Being more consistant with the FHS recommendations that /tmp is flushed on reboot https://www.pathname.com/fhs/pub/fhs-2.3.html#TMPTEMPORARYFILES
All of these reasons also apply for regular openSUSE, so I would like to propose that Tumbleweed moves to tmpfs for /tmp soon also.
The impact should be minimal, as all POSIX compliant applications should already assume that /tmp is not persistant between invocations of the program.
Hmm since most people in this thread are just concerned with persistency and/or memory usage, let's raise a different "issue":) Using tmpfs for /tmp might break existing (broken) workflows that assume that /tmp is not a tmpfs (or ramfs). For instance, consider the following _artificial_ script: - rm -rf /tmp/build-root-test-non-shared-mem - install required packages into /tmp/build-root-test-non-shared-mem - do not mount anything into /tmp/build-root-test-non-shared-mem/* - chroot /tmp/build-root-test-non-shared-mem /usr/bin/foo where foo.c looks like this (excerpt) int fd = shm_open("/foo", O_RDWR | O_CREAT, S_IRUSR | S_IWUSR); if (fd == -1) { // non-shared memory mode return do_non_shared_mem_mode(); } // shared memory mode return do_shared_mem_mode(fd); If "suddenly" tmpfs is used for /tmp, the script would not test the "intended" codepath (do_non_shared_mem_mode()) anymore... (A real world application in this chroot scenario is firefox: in the non tmpfs case, you cannot start firefox from within the chroot (it complains about missing shared mem support); in the tmpfs case, firefox can be started from within the chroot (if a /proc is also mounted).)
As we're walking paths that other distros long have, my own research suggests that vast majority of problematic /tmp use has already been resolved, such as by using /var/tmp instead.
We will likely impliment this as systemd mount unit, meaning if people disable it then they will be able to return to the old behaviour.
Would existing installations be affected by this change after a "zypper dup" or is this solely about new/fresh installations? As long as it is just about the latter, breaking workflows like the one from above is perfectly fine for me... Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org