Introducing /run
Introducing /run
Posted Mar 30, 2011 18:19 UTC (Wed) by rleigh (guest, #14622)In reply to: Introducing /run by martinfick
Parent article: Introducing /run
Keeping them separate also means users can't DoS the system by using all the space/inodes and thus prevent the creation of new pidfiles/lockfiles etc.
Regards,
Roger
Posted Mar 30, 2011 19:01 UTC (Wed)
by dmarti (subscriber, #11625)
[Link] (31 responses)
Posted Mar 30, 2011 19:49 UTC (Wed)
by makomk (guest, #51493)
[Link] (10 responses)
Posted Mar 30, 2011 19:56 UTC (Wed)
by dmarti (subscriber, #11625)
[Link] (9 responses)
Any examples of programs that put something important in there?
Posted Mar 30, 2011 20:59 UTC (Wed)
by nix (subscriber, #2304)
[Link] (4 responses)
(TBH I much prefer this over the vim habit of scattering .swp files everywhere. Emacs has a similar feature: you can drop all autosave files into a single directory without much effort.)
Posted Mar 30, 2011 21:18 UTC (Wed)
by cortana (subscriber, #24596)
[Link] (2 responses)
Posted Apr 1, 2011 17:28 UTC (Fri)
by nix (subscriber, #2304)
[Link] (1 responses)
Posted Apr 1, 2011 19:13 UTC (Fri)
by dtlin (subscriber, #36537)
[Link]
Posted Mar 31, 2011 12:38 UTC (Thu)
by NAR (subscriber, #1313)
[Link]
Posted Mar 30, 2011 21:06 UTC (Wed)
by fritsd (guest, #43411)
[Link]
Posted Mar 30, 2011 21:12 UTC (Wed)
by nybble41 (subscriber, #55106)
[Link] (2 responses)
That said, I don't specifically know whether any common programs store data in /var/tmp which must persist across a reboot. I do know that MySQL occasionally stores certain temporary files there; these may be need for recovery after a crash or power interruption. KDE also stores cache files under /var/tmp; losing these at every reboot would be likely to negatively impact performance.
Posted Mar 31, 2011 0:02 UTC (Thu)
by nicooo (guest, #69134)
[Link]
Posted May 4, 2011 21:36 UTC (Wed)
by nix (subscriber, #2304)
[Link]
Posted Mar 30, 2011 19:59 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (18 responses)
Posted Mar 30, 2011 20:27 UTC (Wed)
by Darkmere (subscriber, #53695)
[Link]
Posted Mar 30, 2011 23:36 UTC (Wed)
by roblucid (guest, #48964)
[Link] (12 responses)
/tmp is meant to be small, fast and ephemeral, with a purge across a reboot being acceptable or clean out if the file's not accessed for a day or so.
Of course if you *must* have a /tmp/humungeous then nothing to stop a mount under /tmp, or a symlink to fallow area, for you to fill.
Posted Mar 31, 2011 2:20 UTC (Thu)
by k8to (guest, #15413)
[Link] (1 responses)
2 - on Linux, at least (this is LWN) there is little advantage of tmpfs over a normal filesystem for tmp. Linux's filesystem layer is quite good about not needing to send out data to disk when unnecessary (a truly shortlived file may never see the disk at all), and for the longer lived or large file case you get perfectly reasonable behavior as well
Posted Mar 31, 2011 21:36 UTC (Thu)
by jond (subscriber, #37669)
[Link]
Posted Mar 31, 2011 12:57 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (8 responses)
And why shouldn't they?
Posted Mar 31, 2011 17:00 UTC (Thu)
by vonbrand (subscriber, #4458)
[Link] (7 responses)
Because
Posted Mar 31, 2011 17:54 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
Sticky bit for directories was specifically invented for the world-writable /tmp. Also, where should user processes store their temporary data (for example, if a user opens a .tgz file in Nautilus)?
/home might be on a slow NFS link, so it's an incorrect answer.
Posted Mar 31, 2011 19:43 UTC (Thu)
by vonbrand (subscriber, #4458)
[Link] (1 responses)
The user temporary files are supposed to go in
Posted Mar 31, 2011 19:56 UTC (Thu)
by martinfick (subscriber, #4455)
[Link]
Where do you get that rationale from? The FHS does not think so: The /tmp directory must be made available for programs that require temporary files.
Programs must not assume that any files or directories in /tmp are preserved between invocations of the program.
Tip Rationale
IEEE standard P1003.2 (POSIX, part 2) makes requirements that are similar to the above section.
Although data stored in /tmp may be deleted in a site-specific manner, it is recommended that files and directories located in /tmp be deleted whenever the system is booted.
FHS added this recommendation on the basis of historical precedent and common practice, but did not make it a requirement because system administration is not within the scope of this standard.
Posted Apr 1, 2011 15:55 UTC (Fri)
by k8to (guest, #15413)
[Link]
Posted Apr 1, 2011 17:30 UTC (Fri)
by nix (subscriber, #2304)
[Link] (2 responses)
(FWIW I too have never heard this before. /tmp is transient: /var/tmp is not. That's all.)
Posted Apr 2, 2011 15:15 UTC (Sat)
by vonbrand (subscriber, #4458)
[Link] (1 responses)
The compiler is not a "normal user", it is a system program (run by normal users under their UID, thus the sticky bit on
Posted Apr 2, 2011 17:11 UTC (Sat)
by mpr22 (subscriber, #60784)
[Link]
1) I notice you're still not bothering to provide a citation for "/tmp is for the system and off-limits to ordinary applications". 2) In my world, the C compiler is an ordinary user application, so should use filesystems in the manner appropriate to ordinary user applications.
Posted Mar 31, 2011 13:43 UTC (Thu)
by jschrod (subscriber, #1646)
[Link]
In my world, if one uses applications that place there temporary files in /tmp and produce several GBs of them, it is surely *not* gross user incompetence if one decides not to spend one's time trying to detect how each and every of these apps can be persuaded to place their temporary files somewhere else. Instead one just gives /tmp more space. In my world, this is called pragmatic. Maybe you've heard of that term, but with your quick judgement of others, there is some doubt about that.
Maybe that information is new, but setting aside a few hundred GBs of disk space for /tmp is not really a problem with today's disk sizes. The 90s are over, really. And in no way that stops /tmp from being purged at reboot time.
Btw, if I would really clean out every day all /tmp files not accessed in a day, my desktop would not function any more. /tmp cleaning while user sessions are active needs more care than such coarse treatments; it needs blacklists, and most often also longer retention times.
Posted Apr 1, 2011 21:23 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (3 responses)
BUT it *defaults* to "half available ram".
I got bitten by this when I put /var/tmp into tmpfs on gentoo, and then wondered why OpenOffice wouldn't compile :-)
I always set swap to (at least) twice available ram, which on my system is 32Gb (kernel 2.4 proved that the "twice ram" rule was NOT obsolete, and nobody has yet given me any reason to believe things have changed since then).
I think my tmpfs partitions are all set to about 10-16Gb in size. They're all fine. If you use enough space on the partition, it will simply spill into swap.
Cheers,
Posted Apr 2, 2011 14:28 UTC (Sat)
by dtlin (subscriber, #36537)
[Link] (2 responses)
Posted Apr 2, 2011 23:05 UTC (Sat)
by Wol (subscriber, #4433)
[Link]
But with 8Gb of ram, my system hardly ever swaps, even with /tmp as tmpfs.
However, portage occasionally chews up large amounts of temporary space. Compiling OOo, it recommends you have 10Gb of disk space free in /var/tmp/portage. Chances are, if anything ever gets flushed to swap, it'll never be wanted again, which is why I stick it in tmpfs rather than have it chew up real space in a real partition.
And with 1.5Tb disk across two drives, why should I care about losing 32Gb to swap? :-) It's there if it's needed - which it hardly ever is.
Cheers,
Posted Apr 3, 2011 14:59 UTC (Sun)
by khim (subscriber, #9252)
[Link]
The other problem is /var/tmp, which is now just an extra /tmp that doesn't deserve its own tmpfs, but that some software wants to use. SELinux complains about if you make it a symlink to ../tmp. Bind mount it to /tmp in /etc/fstab?
/tmp and /var/tmp
tmpfs /tmp tmpfs defaults 0 0
/tmp /var/tmp tmpfs bind 0 0
tmpfs as many places as possible FTW.
/tmp and /var/tmp
/tmp and /var/tmp
/tmp and /var/tmp
/tmp and /var/tmp
/tmp and /var/tmp
/tmp and /var/tmp
:h dir
- For Unix and Win32, if a directory ends in two path separators "//"
or "\\", the swap file name will be built from the complete path to
the file with all path separators substituted to percent '%' signs.
This will ensure file name uniqueness in the preserve directory.
(Same with 'bdir'.)
/tmp and /var/tmp
/tmp and /var/tmp
/tmp and /var/tmp
/tmp and /var/tmp
/tmp and /var/tmp
/tmp and /var/tmp
/tmp and /var/tmp
/tmp and /var/tmp
/tmp and /var/tmp
/tmp and /var/tmp
/tmp and /var/tmp
/tmp and /var/tmp
/tmp is supposed to be off-limits for users, it being the place for system temporaries?/tmp and /var/tmp
/tmp and /var/tmp
/var/tmp/tmp and /var/tmp
The /var/tmp directory is made available for programs that require temporary files or directories that are preserved between system reboots. Therefore, data stored in /var/tmp is more persistent than data in /tmp.
Files and directories located in /var/tmp must not be deleted when the system is booted. Although data stored in /var/tmp is typically deleted in a site-specific manner, it is recommended that deletions occur at a less frequent interval than /tmp.
/tmp and /var/tmp
/tmp and /var/tmp
/tmp and /var/tmp
/tmp)./tmp and /var/tmp
/tmp and /var/tmp
/tmp and /var/tmp
Wol
/tmp and /var/tmp
/tmp and /var/tmp
Wol
Yes, if you're constantly swapping your tmpfs you are slowing everything down. But more often then not it's not the case. 80/20> rules is valid for temporary files too. Most temporary files are accessed rarely, but few are accessed constantly - and they don't ever hit the disk with tmpfs. I know that incremental Chromium build is faster on tmpfs then on real fs if you have beefy system (16GB of RAM, 100GB of temporary files in tmpfs).
You 100% right - and still wrong :-)