[arch-projects] [initscripts][RFC] managing /tmp

[Dan McGee]

On Wed, May 18, 2011 at 12:54 PM, Tom Gundersen <teg at jklm.no> wrote:
> On Wed, May 18, 2011 at 7:41 PM, Dave Reisner <d at falconindy.com> wrote:
>> Additionally, clearing /tmp in /etc/rc.local is too late. Daemons are
>> already started at this point. X might even be running. We can't blindly
>> rip out this data. If we really wanted to go this route (and I
>> personally don't think we should), we would need to add another hook
>> within rc.sysint shortly after root is remounted rw, which would be the
>> appropriate time for this to happen.
>
> Meh, you convinced me. I'll just reinstate the old behavior. We will
> not support preserving /tmp.
>
>> I disagree. Arch doesn't push any default setting of mounting tmpfs on
>> /tmp, so I think the majority use case is that the rm call removes
>> something. The opt-in behavior (the edge case) is where this becomes
>> a NOOP.
>
> I guess I rather should have suggested making /tmp as tmpfs the
> default, because there really is no good reason (at least I have not
> been able to find any) for doing anything else (yet people are doing
> it...). I guess a case could be made for keeping /tmp on the root
> device, but I don't think it is a good idea either.

I think the right conclusion has been reached (don't change anything),
but I will add that expecting everyone to have /tmp as a tmpfs is
extremely limiting. I also disagree with your unbacked-with-facts
conclusion that "99.99%" of people are satisfied with a /tmp on tmpfs;
of my 5 machines running Arch only 2 have /tmp on tmpfs. I can think
of several situations where this is just plain impractical:
* Running on a VPS/VM with limited RAM
* Any situation that requires /tmp to be bigger than the size of RAM
(or even bigger than half of it)
* Any setup where I have a highly performant RAID setup (or maybe SSDs
are involved); being on disk will be just fine

-Dan