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

Tom Gundersen

18 May 2011 18 May '11

4:34 p.m.

Hi guys, Thanks to all of you who answered my many previous RFC's, I will follow up on them with code soon :-) In the last initscripts release I inedvertently introduced a bug where /tmp is not cleared on boot if it is mounted on a non-tmpfs drive (it was only cleared if it lived on the root partition). This lead to a long discussion in the bug report about possible use-cases for /tmp. Among other things it was requested that we should stop clearing /tmp or make it configurable. As always, I'm opposed to adding configuration options just for the sake of it, so I propose something different. First of all, this is what I took away from the discussion: 1) /tmp should always be mounted as tmpfs (there are some really obscure scenarios when it should not be (if you have individual files larger than 256GB on it)) 2) if /tmp is not mounted as tmpfs it should always be cleared at boot That said, some users disagree, and want to /tmp to be preserved on reboot. Usually I would deny such a request, but I figured it would actually simplify things, so why not. This is my proposal: 1) We advice users to mount /tmp as tmpfs (possibly with the proviso that the partition they would normally have used for /tmp is turned into swap space, and the size option of /tmp is set to the size of the old partition), this could be added to the standard fstab if we wish. 2) We never touch /tmp at boot. This makes no difference if the users follow our advice. 3) If the user wants to mount /tmp as a different fs, we advice them to put "rm -rf /tmp/* /tmp/.*" in rc.local, or manage /tmp in any other way they want (e.g. by using the tmpwatch package). What do you think? Cheers, Tom

Show replies by date

Dave Reisner

18 May 18 May

5:04 p.m.

On Wed, May 18, 2011 at 06:34:50PM +0200, Tom Gundersen wrote:

...

Hi guys,

Thanks to all of you who answered my many previous RFC's, I will follow up on them with code soon :-)

In the last initscripts release I inedvertently introduced a bug where /tmp is not cleared on boot if it is mounted on a non-tmpfs drive (it was only cleared if it lived on the root partition). This lead to a long discussion in the bug report about possible use-cases for /tmp. Among other things it was requested that we should stop clearing /tmp or make it configurable. As always, I'm opposed to adding configuration options just for the sake of it, so I propose something different.

First of all, this is what I took away from the discussion:

1) /tmp should always be mounted as tmpfs (there are some really obscure scenarios when it should not be (if you have individual files larger than 256GB on it)) 2) if /tmp is not mounted as tmpfs it should always be cleared at boot

That said, some users disagree, and want to /tmp to be preserved on reboot. Usually I would deny such a request, but I figured it would actually simplify things, so why not. This is my proposal:

1) We advice users to mount /tmp as tmpfs (possibly with the proviso that the partition they would normally have used for /tmp is turned into swap space, and the size option of /tmp is set to the size of the old partition), this could be added to the standard fstab if we wish. 2) We never touch /tmp at boot. This makes no difference if the users follow our advice. 3) If the user wants to mount /tmp as a different fs, we advice them to put "rm -rf /tmp/* /tmp/.*" in rc.local, or manage /tmp in any other way they want (e.g. by using the tmpwatch package).

What do you think?

Cheers,

Tom

Looking at the patch that triggered this, I'm confused as to why the logic was added to rc.sysinit to begin with. Why conditionally check for /tmp being mounted? What's the harm in unconditionally calling rm -rf /tmp/*? Has it bitten us in the past? The commit message doesn't even cover this change. dave

Tom Gundersen

5:10 p.m.

On Wed, May 18, 2011 at 7:04 PM, Dave Reisner wrote:

...

Looking at the patch that triggered this, I'm confused as to why the logic was added to rc.sysinit to begin with. Why conditionally check for /tmp being mounted? What's the harm in unconditionally calling rm -rf /tmp/*? Has it bitten us in the past? The commit message doesn't even cover this change.

The original change was completely stupid and will be reverted for the next release (unless we skip the /tmp cleaning altogether). I had been reading bug reports about being able to trick "rm /tmp/*" to delete things outside of /tmp, but I am not able to reproduce it, so I guess the bug reports were bogus. I hadn't intended for this change to be pushed out (that's why it was not in the commit msg), but must have been a bit too eager with the "git add -p"... -t

Dave Reisner

5:24 p.m.

On Wed, May 18, 2011 at 07:10:41PM +0200, Tom Gundersen wrote:

...

On Wed, May 18, 2011 at 7:04 PM, Dave Reisner wrote:

...
Looking at the patch that triggered this, I'm confused as to why the logic was added to rc.sysinit to begin with. Why conditionally check for /tmp being mounted? What's the harm in unconditionally calling rm -rf /tmp/*? Has it bitten us in the past? The commit message doesn't even cover this change.

The original change was completely stupid and will be reverted for the next release (unless we skip the /tmp cleaning altogether). I had been reading bug reports about being able to trick "rm /tmp/*" to delete things outside of /tmp, but I am not able to reproduce it, so I guess the bug reports were bogus. I hadn't intended for this change to be pushed out (that's why it was not in the commit msg), but must have been a bit too eager with the "git add -p"...

-t

I can only think of 1 reason that would happen, and it's completely ridiculous: If you bind mount things into /tmp, then recursively deleting /tmp would nuke things on the mounts as well. I don't think there's a legitimate case for this though. rm does not follow symlinks, and my only other concern would be what happens when nullglob is set and the glob fails to expand-- but a quick test shows that not be a concern either. thanks, dave

Tom Gundersen

5:29 p.m.

On Wed, May 18, 2011 at 7:24 PM, Dave Reisner wrote:

...

I can only think of 1 reason that would happen, and it's completely ridiculous: If you bind mount things into /tmp, then recursively deleting /tmp would nuke things on the mounts as well. I don't think there's a legitimate case for this though.

rm does not follow symlinks, and my only other concern would be what happens when nullglob is set and the glob fails to expand-- but a quick test shows that not be a concern either.

Yes. I tried all these things, and it is (as far as I can tell) no way to exploit this. So we don't need to take this into consideration. The only reason to don't touch /tmp is that a) the less we do, the better b) in 99.99% of all cases it will be a noop anyway c) in the remaining cases there were some users who requested to be able to control the behavior, so why not oblige them ;-) (but they'll have to do it themselves in rc.local). -t

Dave Reisner

5:41 p.m.

On Wed, May 18, 2011 at 07:29:49PM +0200, Tom Gundersen wrote:

...

On Wed, May 18, 2011 at 7:24 PM, Dave Reisner wrote:

...
I can only think of 1 reason that would happen, and it's completely ridiculous: If you bind mount things into /tmp, then recursively deleting /tmp would nuke things on the mounts as well. I don't think there's a legitimate case for this though.

rm does not follow symlinks, and my only other concern would be what happens when nullglob is set and the glob fails to expand-- but a quick test shows that not be a concern either.

Yes. I tried all these things, and it is (as far as I can tell) no way to exploit this. So we don't need to take this into consideration.

The only reason to don't touch /tmp is that a) the less we do, the better b) in 99.99% of all cases it will be a noop anyway c) in the remaining cases there were some users who requested to be able to control the behavior, so why not oblige them ;-) (but they'll have to do it themselves in rc.local).

-t

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

Tom Gundersen

5:54 p.m.

On Wed, May 18, 2011 at 7:41 PM, Dave Reisner 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. -t

Dan McGee

19 May 19 May

9:16 p.m.

On Wed, May 18, 2011 at 12:54 PM, Tom Gundersen wrote:

...

On Wed, May 18, 2011 at 7:41 PM, Dave Reisner 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

Tom Gundersen

10:36 p.m.

On Thu, May 19, 2011 at 11:16 PM, Dan McGee wrote:

...

I think the right conclusion has been reached (don't change anything),

Cool.

...

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

It seems lots of people do this. However, I would like to point out that using tmpfs does not mean that you will use more ram than otherwise. Just like a normal fs will be backed up by a disk a tmpfs will be backed up by swap. So all the above scenarios would be better of with /tmp on tmpfs. (Provided you turn the partition that would otherwise have housed /tmp into swap space and set the size of your /tmp partition equal to the size of your old /tmp partition). The only downside I have found is that there is a 256GB size limit on files on a tmpfs which does not exist on a normal fs. So if you expect to have any particular file be bigger than that, you'd better go with a normal partition. If I'm missing something, please let me know (I have been reading/asking around and about this for a while now, so any info is welcome). Cheers, Tom

Thomas Bächler

20 May 20 May

8:09 a.m.

Am 19.05.2011 23:16, schrieb Dan McGee:

...

[...] 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

In my opinion, /tmp as tmpfs is still a valid default for our fstab. The most common use case for Arch is a server, desktop or laptop with sufficient memory, where this is a good idea. In all other cases, a user has 2 choices: 1) Add sufficient swap space, then add size=10G to the tmpfs size. 2) Remove the tmpfs line from fstab. I don't feel strongly about this though.

Thomas Bächler

8:06 a.m.

Am 18.05.2011 19:24, schrieb Dave Reisner:

...

I can only think of 1 reason that would happen, and it's completely ridiculous: If you bind mount things into /tmp, then recursively deleting /tmp would nuke things on the mounts as well. I don't think there's a legitimate case for this though.

rm --one-file-system

Thomas Bächler

8:02 a.m.

Am 18.05.2011 18:34, schrieb Tom Gundersen:

...

First of all, this is what I took away from the discussion:

1) /tmp should always be mounted as tmpfs (there are some really obscure scenarios when it should not be (if you have individual files larger than 256GB on it))

In low-memory environments, this can be problematic. I had a problem with a third-party installer, because it extracted its files into /tmp. I had 512MB RAM back then, so my /tmp was 256MB only, which was not sufficient (I used no size= option, which was in Arch's default fstab back then).

...

2) if /tmp is not mounted as tmpfs it should always be cleared at boot

That said, some users disagree, and want to /tmp to be preserved on reboot. Usually I would deny such a request, but I figured it would actually simplify things, so why not.

/tmp is not supposed to be preserved between reboots. Some distributions do it (SuSE even leaves it entirely untouched by default, leading to 10 year old files in /tmp). If you want temporary files to be kept between reboots, use /var/tmp/. In my opinion, cleaning /tmp is the right thing to do.

4725

Age (days ago)

4727

Last active (days ago)

List overview

Download

11 comments

4 participants

participants (4)

Dan McGee
Dave Reisner
Thomas Bächler
Tom Gundersen

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

tags

participants (4)