Mailinglist Archive: opensuse-factory (435 mails)

< Previous Next >
Re: [opensuse-factory] Proposal: /tmp as tmpfs
  • From: Marcus Hüwe <suse-tux@xxxxxx>
  • Date: Sat, 11 Jul 2020 23:36:57 +0200
  • Message-id: <20200711213657.recqfstkon2pnttk@linux>
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@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx

< Previous Next >
This Thread
Follow Ups
References