/tmp volatility

fukawi2 · 2008-10-07 00:38:47

What is everyone's experiences with the volatility of files within the /tmp directory?

According to the FHS, it is recommended that the contents of /tmp only be cleared at boot.
http://www.pathname.com/fhs/pub/fhs-2.3 … ORARYFILES

IIRC, I saw somewhere in code that Arch follows this practice. Since Linux often demonstrates extreme lengths of stable uptime, what are some of the other approaches to clearing out old /tmp files that people have come across?

I'm not trying to achieve anything in particular, just a discussion point

dav7 · 2008-10-07 04:29:12

Well I know that rm -rf /tmp/* is a bad idea (no, don't run that if you don't know what it does!).

For starters, X and anything running won't just go *asplosion* *KABOOM*, but nothing new will be able to connect to the X server since its communication pipes have been deleted.

Same for screen.

My point? Periodic emptying of /tmp is a bad idea unless the rm command is limited to a small handful of directories, such as (for example) Audacity's temporary directory.

-dav7

Last edited by dav7 (2008-10-07 04:30:18)

kamituel · 2008-10-07 07:48:10

There is a server at my university which is used by apporx 3000 students (and some other people too). And temp directory is cleared during regular system operation. But I've noticed, that the first files which are about to be deleted are big ones, which are unlikely to be important temporary files used by programs, but rather they are some documents/archives.
Oh, this server runs Solaris, but it does not matter I think.

fumbles · 2008-10-07 08:50:15

kamituel wrote:

Oh, this server runs Solaris, but it does not matter I think.

Solaris, by default, run the /tmp from memory. So I would assume it would be preserve memory. I am also assuming that they are using a script, like check who is using what and remove what they can (still don't know why you would do this). Also (re-reading your post) generally when a programme closes/exits normally or say from a TERM signal it does cleanup and then exits, and therefore deleting what ever it was using in /tmp. Now there are quite a lot of reasons for a programme to dump a whole heaps of data in /tmp and the delete it soon after, basically that is what it is for.

What I do on my University (also Solaris) is have symlinks from my home directory to tmp where I have created a folder to put things which arent that important. Since my University runs two Solaris servers if one goes down (which is rare, Sun systems are rock solid) I've still got my tmp stuff on the other server and it will just copy it from the other when it comes back online.

fyi:

SolarisServer1 ~ $ du -sh /tmp
533M /tmp
SolarisServer1 ~$ uptime
7:51pm up 63 day(s), 20:07, 104 users, load average: 5.00, 4.79, 4.67
SolarisServer2 ~$ uptime
7:51pm up 95 day(s), 18:56, 20 users, load average: 2.30, 2.30, 2.31
SolarisServer1 ~$ df -h /tmp
Filesystem size used avail capacity Mounted on
swap 8.0G 149M 7.9G 2% /tmp
SolarisServer1&2 ~$ uname -pi
sparc SUNW,Sun-Fire-V890

NB: If I have misinterpreted something, or am plain wrong feel free to (in a civilised manor) correct me

Last edited by fumbles (2008-10-07 09:00:53)

B-Con · 2008-10-08 03:23:32

Although this doesn't directly contribute to the point at hand: My method of /tmp control is to just mount /tmp as a RAMFS in my fstab. That way it automatically clears at boot (without even any split-second delay for rm'ing potentially populated directories) and potentially sensitive material never touches my hard drive.

fukawi2 · 2008-10-08 04:11:53

B-Con wrote:

Although this doesn't directly contribute to the point at hand: My method of /tmp control is to just mount /tmp as a RAMFS in my fstab. That way it automatically clears at boot (without even any split-second delay for rm'ing potentially populated directories) and potentially sensitive material never touches my hard drive.

I've thought about that before but never really committed to it. How's it work for you? Any downsides?

B-Con · 2008-10-08 05:10:29

fukawi2 wrote:

B-Con wrote:
Although this doesn't directly contribute to the point at hand: My method of /tmp control is to just mount /tmp as a RAMFS in my fstab. That way it automatically clears at boot (without even any split-second delay for rm'ing potentially populated directories) and potentially sensitive material never touches my hard drive.
I've thought about that before but never really committed to it. How's it work for you? Any downsides?

The only downside I've encountered is when I've failed to make the RAMFS large enough. Thankfully a RAMFS dynamically changes in size, so if you make it 300MB that only means 300MB is the upper bound the RAMFS will never grow larger than. It won't actually use more RAM than there are files in the FS at any given point. So I can throw almost as much size at it as I please.
I have 2GB of RAM and never use more than 600MB of it, so a 500MB RAMFS for /tmp has worked fine. Even on my laptop with 512MB RAM, I use a 200MB RAMFS for /tmp and never encounter any problems. Few things require that much /tmp space, and if you run a relatively light desktop otherwise, you can throw a 100MB or so at a temporary project.

If you have limited RAM (<= 512MB) and plan to do anything /tmp intensive, such as Audacity editing, this *may* not be the solution for you, since the /tmp FS will fill quickly. But the exacts will vary. In general, I think it should work fine. Note that you may want to have a SWAP partition if you do this on a minimal RAM computer, because running out of RAM and not having SWAP available really sucks. Not that it will necessarily happen, but if it does, it would suck.

fukawi2 · 2008-10-08 08:22:25

Cool - done on my machine now according to http://wiki.linuxquestions.org/wiki/Tmpfs

Now to wait for next reboot so it can take effect

fumbles · 2008-10-08 10:30:08

Speaking of which, IIRC there is a difference between tmpfs and ramfs: ramfs doesn't use swap, unlike tmpfs.

tmpfs is supported by the Linux kernel from version 2.4 and up.[3] tmpfs (previously known as shmfs) distinguishes itself from the Linux ramdisk device by allocating memory dynamically and by allowing less-used pages to be moved onto swap space. RAMFS, in contrast, does not make use of virtual memory

Wikipeda, so grain of salt.

fflarex · 2008-10-08 18:14:24

Isn't /tmp a sticky directory, meaning that you can't manually delete the files under it? (at least not without unstickying it)

Arch Linux

#1 2008-10-07 00:38:47

/tmp volatility

#2 2008-10-07 04:29:12

Re: /tmp volatility

#3 2008-10-07 07:48:10

Re: /tmp volatility

#4 2008-10-07 08:50:15

Re: /tmp volatility

#5 2008-10-08 03:23:32

Re: /tmp volatility

#6 2008-10-08 04:11:53

Re: /tmp volatility

#7 2008-10-08 05:10:29

Re: /tmp volatility

#8 2008-10-08 08:22:25

Re: /tmp volatility

#9 2008-10-08 10:30:08

Re: /tmp volatility

#10 2008-10-08 18:14:24

Re: /tmp volatility

Board footer