rack-devel archive mirror (unofficial) https://groups.google.com/group/rack-devel
 help / color / mirror / code / Atom feed
From: Charles Oliver Nutter <headius@headius.com>
To: rack-devel@googlegroups.com
Subject: Re: Not cleaning up tempfiles for multipart?
Date: Sun, 7 Mar 2010 08:34:25 -0600	[thread overview]
Message-ID: <f04d2211003070634n18419af5t38a59e2e394fff7@mail.gmail.com> (raw)
In-Reply-To: <44f3f951-889e-45ec-ae46-40a371329a9e@e1g2000yqh.googlegroups.com>

On Sat, Mar 6, 2010 at 4:25 AM, Hongli Lai <hongli@phusion.nl> wrote:
>> Why not?  Tempfiles are objects, too.  It's perfectly reasonable
>> to let GC clean them up like any other object.
>
> Phusion Passenger terminates worker processes by calling exit!. This
> does not call finalizers on MRI, causing temp files to be left behind
> sometimes. There seems to be no way to call finalizers, even GC.start
> doesn't work. I too would like to see Tempfiles being cleaned up
> explicitly.

We did run into some difficulties proving that MRI cleans up old files
when it GCs, mostly because of quirks in the GC (constructing the
tempfile in a method body kept it alive even when it wasn't
referenced, but constructing it in a block invocation allowed it to
GC...MRI's GC baffles me sometimes). But we did confirm it...it's just
unreliable in certain cases (and obviously if you exit! it's totally
useless, since the process just disappears and leaves files behind).

All IO-related objects should be explicitly cleaned up, without
exception...including the unlink of a tempfile once it's no longer
needed.

> Other than that, I've seen system administrators who are confused by
> the fact that such Tempfiles are not immediately cleaned up. Some
> people who operate websites that handle a large number of concurrent
> uploads are worried that they might run out of disk space because of
> this.

This is what we ran into. Because of a bug in JRuby 1.4, our new
Tempfile impl was only unlinking them on exit (or when explicitly told
to do so, of course). A user eventually filled their temp space since
various Ruby libraries did not explicitly close! Tempfile resources,
including Rack (attachment_fu was the other one...have not looked into
that yet).

Yes, JRuby was incorrect to not unlink tempfiles on GC, but Rack (and
any other Ruby library dong the same) is broken if it does not clean
up tempfiles once they're no longer needed.

I'm certainly willing to help fix Rack, but I'm not sure where would
be the best place to close! the tempfile.

- Charlie

  reply	other threads:[~2010-03-07 14:34 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-05 14:40 Charles Oliver Nutter
2010-03-05 14:47 ` Charles Oliver Nutter
2010-03-05 14:48   ` Charles Oliver Nutter
2010-03-06 10:20   ` Hongli Lai
2010-03-07 14:25     ` Charles Oliver Nutter
2010-03-06  7:55 ` Eric Wong
2010-03-06 10:25   ` Hongli Lai
2010-03-07 14:34     ` Charles Oliver Nutter [this message]
2010-03-08  0:22       ` Eric Wong
2010-03-08  1:12         ` Eric Wong
2010-03-17 15:41           ` Charles Oliver Nutter
2010-03-18  9:54             ` Eric Wong
2014-01-06 22:45               ` Wojtek Kruszewski
2014-02-11 21:05                 ` Eric Wong
2014-03-27 21:40                   ` Lenny Marks
2010-03-07 23:53     ` Eric Wong
2010-03-08 11:26       ` Hongli Lai
2010-03-08 11:30         ` Hongli Lai
2010-03-08 14:33           ` Randy Fischer
2010-03-08 14:43           ` Charles Oliver Nutter
2010-03-08 14:49             ` James Tucker
2010-03-17  2:37           ` Eric Wong
2010-03-08 13:22         ` Charles Oliver Nutter
2010-03-08 14:42         ` James Tucker
2010-03-08 17:24           ` Hongli Lai
2010-03-09  7:43             ` Charles Oliver Nutter
2010-03-08 10:05     ` James Tucker
2010-03-07 14:27   ` Charles Oliver Nutter
2010-03-08  0:18     ` Eric Wong
2010-03-08 10:07       ` James Tucker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://groups.google.com/group/rack-devel

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f04d2211003070634n18419af5t38a59e2e394fff7@mail.gmail.com \
    --to=rack-devel@googlegroups.com \
    --subject='Re: Not cleaning up tempfiles for multipart?' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Code repositories for project(s) associated with this inbox:

	https://80x24.org/mirrors/rack.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).