|
|
Log in / Subscribe / Register

Introducing /run

Introducing /run

Posted Mar 30, 2011 17:45 UTC (Wed) by martinfick (subscriber, #4455)
Parent article: Introducing /run

Could /tmp just become a link to /run/tmp then?

to post comments

Introducing /run

Posted Mar 30, 2011 18:19 UTC (Wed) by rleigh (guest, #14622) [Link] (32 responses)

/run may well have much a smaller size than /tmp, and they have rather different purposes. /run will typically contain small files (pidfiles, lockfiles, other small bits of system state etc.) while /tmp is intended to contain arbitrary user data, which may be significantly larger.

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

/tmp and /var/tmp

Posted Mar 30, 2011 19:01 UTC (Wed) by dmarti (subscriber, #11625) [Link] (31 responses)

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? 
tmpfs			/tmp			tmpfs	defaults	0 0
/tmp			/var/tmp		tmpfs	bind		0 0
tmpfs as many places as possible FTW.

/tmp and /var/tmp

Posted Mar 30, 2011 19:49 UTC (Wed) by makomk (guest, #51493) [Link] (10 responses)

Putting /var/tmp/ is on a tmpfs not just a violation of the LSB filesystem layout requirements, it's likely to lead to data loss. /var/tmp/ is required to be preserved across reboots.

/tmp and /var/tmp

Posted Mar 30, 2011 19:56 UTC (Wed) by dmarti (subscriber, #11625) [Link] (9 responses)

But it's allowed to be cleaned out, like any temp directory, right? I don't reboot often enough that a "tmpwatch" or cron job would run any less often than a reboot.

Any examples of programs that put something important in there?

/tmp and /var/tmp

Posted Mar 30, 2011 20:59 UTC (Wed) by nix (subscriber, #2304) [Link] (4 responses)

Original vi / nvi puts files in there for use by virecover. You really want those to still be there after e.g. a power cut.

(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.)

/tmp and /var/tmp

Posted Mar 30, 2011 21:18 UTC (Wed) by cortana (subscriber, #24596) [Link] (2 responses)

And for those who are wondering, you can set vim's 'directory' option to '/var/tmp' to get this behaviour back.

/tmp and /var/tmp

Posted Apr 1, 2011 17:28 UTC (Fri) by nix (subscriber, #2304) [Link] (1 responses)

Oo, thanks, hadn't noticed that. It doesn't record the pathname anywhere, though, so collisions are quite likely. (Emacs and XEmacs encode the pathname in the autosave filename.)

/tmp and /var/tmp

Posted Apr 1, 2011 19:13 UTC (Fri) by dtlin (subscriber, #36537) [Link] 

: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

Posted Mar 31, 2011 12:38 UTC (Thu) by NAR (subscriber, #1313) [Link]

On the other hand if I edit a file on NFS from one computer, then vim can't use the /var/tmp from an other computer...

/tmp and /var/tmp

Posted Mar 30, 2011 21:06 UTC (Wed) by fritsd (guest, #43411) [Link]

Doesn't vi use /var/tmp for its crash-recovery files?

/tmp and /var/tmp

Posted Mar 30, 2011 21:12 UTC (Wed) by nybble41 (subscriber, #55106) [Link] (2 responses)

Tools like tmpwatch remove *old* temporary files; a reboot could potentially wipe out *recent* files which still contain needed data.

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.

/tmp and /var/tmp

Posted Mar 31, 2011 0:02 UTC (Thu) by nicooo (guest, #69134) [Link]

Shouldn't they be using /var/cache?

/tmp and /var/tmp

Posted May 4, 2011 21:36 UTC (Wed) by nix (subscriber, #2304) [Link]

KDE rebuilds those cache files at every startup anyway.

/tmp and /var/tmp

Posted Mar 30, 2011 19:59 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (18 responses)

In a couple of cases I've used /tmp to hold several hundred gigabytes of data. I don't think tmpfs can cope with such usage.

/tmp and /var/tmp

Posted Mar 30, 2011 20:27 UTC (Wed) by Darkmere (subscriber, #53695) [Link]

/tmp tends to be the place where things like webbrowsers store movies you cache and download... with the advent of HD video streaming, these can be interestingly large.

/tmp and /var/tmp

Posted Mar 30, 2011 23:36 UTC (Wed) by roblucid (guest, #48964) [Link] (12 responses)

100's of GB in /tmp, that's GUI error (Gross User Incompetence) or just bad taste if you prefer.

/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.

/tmp and /var/tmp

Posted Mar 31, 2011 2:20 UTC (Thu) by k8to (guest, #15413) [Link] (1 responses)

1 - tmp is not meant to be small, it is meant to be temporary, it is only broken unixes which used special filessytems for tmp which could not support large temporary files, which do exist

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

/tmp and /var/tmp

Posted Mar 31, 2011 21:36 UTC (Thu) by jond (subscriber, #37669) [Link]

Absolutely. And I've seen veteran UNIX sysadmins dump e.g. Oracle install data in /tmp on solaris systems, which *do* use tmpfs for /tmp, thus knackering the box... it's expected to be able to do it, even when it isn't a good idea :-)

/tmp and /var/tmp

Posted Mar 31, 2011 12:57 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (8 responses)

That 100GB were for intermediate data in video processing. They are put in /tmp by default.

And why shouldn't they?

/tmp and /var/tmp

Posted Mar 31, 2011 17:00 UTC (Thu) by vonbrand (subscriber, #4458) [Link] (7 responses)

Because /tmp is supposed to be off-limits for users, it being the place for system temporaries?

/tmp and /var/tmp

Posted Mar 31, 2011 17:54 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

Whiskey Tango Foxtrot?

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.

/tmp and /var/tmp

Posted Mar 31, 2011 19:43 UTC (Thu) by vonbrand (subscriber, #4458) [Link] (1 responses)

The user temporary files are supposed to go in /var/tmp

/tmp and /var/tmp

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:

  • /tmp : Temporary files Purpose

      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.

  • /var/tmp : Temporary files preserved between system reboots Purpose
      • 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

    Posted Apr 1, 2011 15:55 UTC (Fri) by k8to (guest, #15413) [Link]

    If /tmp was not for users, then the sticky bit would not have been added to unix to specifically support /tmp for users.

    /tmp and /var/tmp

    Posted Apr 1, 2011 17:30 UTC (Fri) by nix (subscriber, #2304) [Link] (2 responses)

    Uh, GCC dumps stuff in /tmp if you don't specify -pipe. Is the compiler something normal users shouldn't run now?

    (FWIW I too have never heard this before. /tmp is transient: /var/tmp is not. That's all.)

    /tmp and /var/tmp

    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 /tmp).

    /tmp and /var/tmp

    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.

    /tmp and /var/tmp

    Posted Mar 31, 2011 13:43 UTC (Thu) by jschrod (subscriber, #1646) [Link]

    GUI judgement is gross arrogance, or just bad human judgement if you prefer.

    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.

    /tmp and /var/tmp

    Posted Apr 1, 2011 21:23 UTC (Fri) by Wol (subscriber, #4433) [Link] (3 responses)

    tmpfs can cope with huge amounts of data no problem.

    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,
    Wol

    /tmp and /var/tmp

    Posted Apr 2, 2011 14:28 UTC (Sat) by dtlin (subscriber, #36537) [Link] (2 responses)

    Spinning disk filesystems try hard to keep data contiguous; swap does a relatively poorer job of it. So if you're constantly swapping your tmpfs, it's likely slower than if you just used a dedicated filesystem.

    /tmp and /var/tmp

    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,
    Wol

    You 100% right - and still wrong :-)

    Posted Apr 3, 2011 14:59 UTC (Sun) by khim (subscriber, #9252) [Link]

    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).

    /tmp and /var/tmp

    Posted Apr 1, 2011 20:48 UTC (Fri) by nicooo (guest, #69134) [Link]

    The OpenBSD man page for hier makes the difference clearer.

    Introducing /run

    Posted Mar 31, 2011 13:29 UTC (Thu) by jschrod (subscriber, #1646) [Link]

    Please not: My desktop's main memory (8 GB) would not be sufficient to hold /tmp. Using tmpfs for /tmp is not a given.


    Copyright © 2026, Eklektix, Inc.
    Comments and public postings are copyrighted by their creators.
    Linux is a registered trademark of Linus Torvalds