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 :) > and all apps will continue to work just fine as > if they had not been deleted at all :-)
