Re: [gentoo-user] Re: unix philosophy question for old farts: the original purpose for /tmp ?
On 16/12/2014 20:05, walt wrote: > On 12/15/2014 11:17 PM, Alan McKinnon wrote: >> On 16/12/2014 02:17, walt wrote: >>> I confess I've never thought much about why /tmp exists, but today I was >>> inconvenienced when an end-user utility (uudeview) ran out of space on /tmp >>> while doing an ordinary end-user task processing very large end-user files. >>> >>> Why is an end-user program using a "system" directory like /tmp in the first >>> place? >>> >>> I suspect that the need for /tmp is now gone, but I'm prepared to be wrong >>> :) >>> >>> >>> >> >> >> /tmp was always intended to be used exactly the way you are using it: >> >> yes, it is a "system directory" because it's located in / but you have >> permissions to use it. The mode is 1777 so everyone can >> read/write/execute the contents but it's also sticky (the 1) so only you >> can delete what you put there. It's a general-use scratch pad area that >> everyone can use safely, unfortunately in these days of huge cheap disks >> some apps abuse it by writing gigantic files there and you run out of space. >> >> How have you set /tmp up? Is it on-disk or a tmpfs? You might need to >> make it bigger. > > systemd puts /tmp on a tmpfs by default, and this ancient machine has a mere > 4GB of ram :) I didn't know about the TMPDIR environment (thanks, redwolfe) > so I worked around the problem by rebooting with openrc, which uses my > original > /tmp on the hard drive. (Exactly the excuse I need to buy more RAM :) > > >> /tmp is still very much in use and very much needed, it isn't going >> anywhere soon. The FHS has something interesting to say about /tmp, >> along the lines of: >> >> "A general use scratch pad area where files written are not expected to >> survive successive invocations of the program that wrote them". That's >> interesting as it means the sysadmin can delete everything in /tmp at >> any time for any reason, > > bofh can delete them for no reason at all while you're still using them :) Exactly :-) And as long as the app doesn't close the file descriptor, everything will continue to work just fine. I used to do this for fun about once a week or so on a many multiuser host, then tell users to tell upstream to fix the stupid bugs in any apps that broke. I've calmed down since then, must have something to do with the onset of senility... -- Alan McKinnon alan.mckin...@gmail.com
RE: [gentoo-user] Re: unix philosophy question for old farts: the original purpose for /tmp ?
From: Alan McKinnon [mailto:alan.mckin...@gmail.com] Sent: Tuesday, December 16, 2014 2:46 PM > On 16/12/2014 20:05, walt wrote: > > On 12/15/2014 11:17 PM, Alan McKinnon wrote: > >> /tmp is still very much in use and very much needed, it isn't going > >> anywhere soon. The FHS has something interesting to say about /tmp, > >> along the lines of: > >> > >> "A general use scratch pad area where files written are not expected to > >> survive successive invocations of the program that wrote them". That's > >> interesting as it means the sysadmin can delete everything in /tmp at > >> any time for any reason, > > > > bofh can delete them for no reason at all while you're still using them :) > > Exactly :-) > > And as long as the app doesn't close the file descriptor, everything > will continue to work just fine. I used to do this for fun about once a > week or so on a many multiuser host, then tell users to tell upstream to > fix the stupid bugs in any apps that broke. I've calmed down since then, > must have something to do with the onset of senility... I used to do this myself every so often, in a fit of hard drive neatness OCD. Then I discovered that ssh-agent decided that a good default place to put its domain socket was /tmp/ssh-XX and deleting it breaks ssh key forwarding, among other things :\ --Mike
Re: [gentoo-user] Re: unix philosophy question for old farts: the original purpose for /tmp ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 17/12/14 08:32, Mike Edenfield wrote: "A general use scratch pad area where files written are not expected to survive successive invocations of the program that wrote them". That's interesting as it means the sysadmin can delete everything in /tmp at any time for any reason, >> >> And as long as the app doesn't close the file descriptor, >> everything will continue to work just fine. I used to do this for >> fun about once a week or so on a many multiuser host, then tell >> users to tell upstream to fix the stupid bugs in any apps that >> broke. I've calmed down since then, must have something to do >> with the onset of senility... > > Then I discovered that ssh-agent decided that a good default place > to put its domain socket was /tmp/ssh-XX and > deleting it breaks ssh key forwarding, among other things :\ I think a key point has been missed here, and that is use of the words "successive invocation". To me, /tmp is an area where files that are /not meant to be permanent/ are able to be written without contaminating the file system and without requiring open permissions in other more sensitive areas like /usr/share or /etc/randomdir. A single invocation of a program having its /tmp contents removed and then acting abnormally isn't something that I would consider a bug. It's when a _subsequent_ run fails because it's expecting a file that is, at least by it's location, _temporary_. One analogy may be that in driving a car, you expect that the engine is running, but it is only required whilst the car is being driven (therefore temporary - only required for that specific invocation). If you suddenly stop the engine when you're halfway to where you're going, within that invocation, you're going to have a bad time. If a program is expecting a dynamically generated file that isn't in the "normal" file system hierarchy, then that file should probably be stored in somewhere like /var or /usr, rather than /tmp. Well, that's my loose change worth. Also, it's early for me - please excuse any bad analogies. :-) - -- wraeth GnuPG Key: B2D9F759 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlSQr1YACgkQXcRKerLZ91kh2AD9HrxjihW5NqY673Af+GRCq6Bj kKsyiBUMJAVTkz96fJoA/2P6y3U5drh5Yma5uFRfK+l1YOdrsKj5LPVHBIa7Egpx =HmpB -END PGP SIGNATURE-
Re: [gentoo-user] Re: unix philosophy question for old farts: the original purpose for /tmp ?
On Tue, Dec 16, 2014 at 1:05 PM, walt wrote: > > systemd puts /tmp on a tmpfs by default. True, but there was pushback by Fedora developers when this became the default so Lennart patched systemd for a "/tmp" mount in "/etc/fstab" to override "/lib/systemd/system/tmp.mount". A pseudo-policy (pseudo since it wasn't, AFAIK, an official policy) was instituted whereby applications that were creating large files in "/tmp" should be patched to use "/var/tmp".
Re: [gentoo-user] Re: unix philosophy question for old farts: the original purpose for /tmp ?
On Wed, Dec 17, 2014 at 4:05 AM, Tom H wrote: > > A pseudo-policy (pseudo since it wasn't, AFAIK, an official policy) > was instituted whereby applications that were creating large files in > "/tmp" should be patched to use "/var/tmp". > This has been the norm on Gentoo for ages - this is why package builds happen in /var/tmp. Many Gentoo users tend to mount /tmp as tmpfs. Actually, many tend to mount /var/tmp as tmpfs as well if they can afford the RAM - it GREATLY improves build times. I moved to building kernels in /var/tmp for the same reason. About the only time I find myself overriding TMPDIR is if I'm running sort on a large file (multi-GB). Merge sorts tend to be heavy on disk use, but fortunately sequential in disk access, so it makes sense to dump them to a disk if they're large. -- Rich
