When to mount /tmp (and other temporary directories)

Question

When is the right time to mount /tmp (on Debian)? For /home I would not feel bad just to echo "/dev/foo /home type defaults 0 0" >>/etc/fstab - but can I be sure that /tmp is not used by any programs when the fstab is applied?

---

I am using either Ubuntu or plain Debian or Debian/Grml - this would not make much difference I guess.

What I have read so far:

• The internet is full of advice to just add tmpfs /tmp tmpfs <optionns> 0 0 - but I am unsure.

• I found this answer on what to do when /tmp is full without rebooting (in short: It's best to reboot anyway, except maybe for a union mount).

• The [Deban policy] does not explain where to add the mount, or when the first access to /tmp may happen. More helpful are /etc/init.d/README and /etc/rcS/README on my Ubuntu (read them online).

Background: I am going to use some Debian flavor on my Netbook (no HD, 8 GB SSD, 1 GB RAM - will double the RAM when neccessary). I am not low on memory. Some tasks are much too slow (building medium-sized C programs or compiling PDF from TeX both take 5+ seonds), but they take no time on a tmpfs. I want to mount a tmpfs on /tmp to accelerate them.

Solution 1

This doesn't appear to be explicitly specified by the Debian policy, but Debian does support making /tmp a separate filesystem (as well as /home, /var and /usr). This is traditionally supported by unix systems. And I can confirm that making /tmp a tmpfs filesystem, and mounting it automatically via /etc/fstab, does work on Debian.

There is some difficulty in transitioning to /tmp on tmpfs on a live system, because of the files that are already in /tmp and cannot be copied. But no file in /tmp is expected to be saved across reboots. It is safe to mount a different filesystem to /tmp at the time the partitions in /etc/fstab are mounted.

Solution 2

In general, you should telinit 1 before mounting over your current /tmp directory. In single-user mode, there should be no files in /tmp that are required for system operation, so you should be able to clean out the directory, unmount it (if it's a separate partition), and then mount something else at that mount point before returning to multi-user mode.

To ensure /tmp is not in use:

1. When /tmp is a mounted filesystem, fuser -m /tmp will verify that no processes are currently using the mount point before you modify it.
2. When /tmp is not a separate filesystem, find /tmp -print0 | xargs -0 fuser will give you similar results.

You might also consider mounting a separate tmpfs filesystem, and exporting TMPDIR (or your compiler's similar environment variables) to make use of it. That would give you the benefit of a tmpfs scratch space without requiring system-wide changes.

Solution 3

tmp should not be used for persistent data

The LSB (Linux Standard Base) defines in the FHS (FilesystemHierarchyStandard) 2.3 that

"Programs must not assume that any files or directories in /tmp are preserved between invocations of the program."

As Gilles has pointed out, this may include sockets for running programs. Most of these programs are propably network services, located in runlevel 2 or 3.

To get detail info for your system:

cd /etc/init.d ; grep tmp * should show you usage of tmp during boot.

Do an additional grep mktemp * to look for higher-level usage of tmp.

Every program should use tmp only very shortly.

On your running system do fuser /tmp/* ; fuser /tmp/*/* and so on to check for running processes blocking tmp.

Apart from that /etc/fstab should be a standard place for mounting filesystems - why should you not add it with "1 2"?

Comments

[anacron]

I am now confident that mounting /tmp from the /etc/fstab is not any problem. Thanks to Gilles, Nils, Mikel, emory, CodeGnome!

[Gilles 'SO- stop being evil']

Your first sentence is wrong. On a desktop machine, there is a file in tmp that is in permanent use: /tmp/.X11-unix/X0, the socket that all X programs use to communicate to the server.

[emory]

Making /home, /tmp, /var/tmp a separate filesystem is an official NSA policy. I don't know about /var and /usr. Why are they recommended?

[anacron]

@Gilles: Since in my case, everything will happen before X comes into play, this should be okay.

[glglgl]

I always found transitioning /tmp very easy. I usually do mv /tmp /tmp.old; mkdir -m 0 /tmp; mount /tmp; ln -s /tmp.old/* /tmp after adding the said line to the fstab. Then the open files in the old /tmp are to be found in /tmp.old and nevertheless can be accessed via /tmp. Then I check if they are used any longer, and after the next reboot, I remove /tmp.old.

[Gilles 'SO- stop being evil']

@Nils Your judgement that it's very bad style is not shared by the authors of X servers, or other programs that put sockets in /tmp. This opinion that files in /tmp are short-lived is not a common one. The key characteristics of /tmp is that the files there are not expected to survive a reboot.

[Gilles 'SO- stop being evil']

@Nils This doesn't contradict the common practice of putting sockets in /tmp in any way. These sockets are not supposed to survive an instance of the server. It doesn't prevent the server (and hence the socket) from remaining for a long time — for a desktop machine, typically, from a few seconds after boot to a few seconds before shutdown.

[Gilles 'SO- stop being evil']

@Nils Not really, it's your first sentence that I find misleading. /tmp is pretty much defined by not being kept across reboots, and also sometimes for deleting unused files. But on a machine with long uptime, files that are in use can remain in /tmp for as long as the machine is up. P.S. I don't think I have anything to add to this debate, if you really want to continue I'm almost always logged in to chat.

[Nils]

@Gilles I changed my answer - so let`s delete this discussion from the comments...