Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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.

share|improve this question
    
I am now confident that mounting /tmp from the /etc/fstab is not any problem. Thanks to Gilles, Nils, Mikel, emory, CodeGnome! –  Mark Apr 22 '12 at 5:02
add comment

4 Answers

up vote 2 down vote accepted

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.

share|improve this answer
    
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? –  emory Apr 22 '12 at 2:12
    
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. –  glglgl Apr 22 '12 at 9:09
add comment

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"?

share|improve this answer
1  
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. –  Gilles Apr 21 '12 at 23:29
    
@Gilles: Since in my case, everything will happen before X comes into play, this should be okay. –  Mark Apr 22 '12 at 4:56
    
@Nils: Thank you for this cheap and valuable hint! Though I did read some stuff about or under /etc/init.d, using grep really is enlighting! –  Mark Apr 22 '12 at 4:57
    
@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 Apr 22 '12 at 21:23
    
@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 Apr 24 '12 at 20:33
show 2 more comments

/etc/fstab is only used when something runs mount.

The three times I can think of:

  • during system boot (on a Debian system, this is early during boot via /etc/rcS.d/S10mountall.sh)
  • when superuser runs mount -a
  • when superuser runs mount <mount point mentioned in /etc/fstab>

If you're saying you want to create a new tmpfs for programs you're about to run, but without rebooting, I think you'll have to mount it somewhere other than /tmp so you don't break programs that are already running.

Why not just

mkdir /tmpnew
mount -t tmpfs tmpfs /tmpnew
TMPDIR=/tmpnew make...
share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.