From: Charles Oliver Nutter <firstname.lastname@example.org> To: email@example.com Subject: Re: Not cleaning up tempfiles for multipart? Date: Sun, 7 Mar 2010 08:34:25 -0600 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <email@example.com> On Sat, Mar 6, 2010 at 4:25 AM, Hongli Lai <firstname.lastname@example.org> 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
next prev parent 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 \ --email@example.com \ --firstname.lastname@example.org \ --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).