From mboxrd@z Thu Jan 1 00:00:00 1970 Delivered-To: chneukirchen@gmail.com Received: by 10.140.140.3 with SMTP id n3cs387015rvd; Sun, 7 Mar 2010 06:34:50 -0800 (PST) Received-SPF: pass (google.com: domain of 3h7mTSwcLCiADA69EQODA69EQO.8KIN68G-9ARAHCKKCHACNKQLO.8KI@groups.bounces.google.com designates 10.224.5.209 as permitted sender) client-ip=10.224.5.209; Authentication-Results: mr.google.com; spf=pass (google.com: domain of 3h7mTSwcLCiADA69EQODA69EQO.8KIN68G-9ARAHCKKCHACNKQLO.8KI@groups.bounces.google.com designates 10.224.5.209 as permitted sender) smtp.mail=3h7mTSwcLCiADA69EQODA69EQO.8KIN68G-9ARAHCKKCHACNKQLO.8KI@groups.bounces.google.com; dkim=pass header.i=3h7mTSwcLCiADA69EQODA69EQO.8KIN68G-9ARAHCKKCHACNKQLO.8KI@groups.bounces.google.com Received: from mr.google.com ([10.224.5.209]) by 10.224.5.209 with SMTP id 17mr1187822qaw.2.1267972488472 (num_hops = 1); Sun, 07 Mar 2010 06:34:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=beta; h=domainkey-signature:received:x-beenthere:received:received:received :received:received-spf:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to :x-original-authentication-results:x-original-sender:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :x-thread-url:x-message-url:sender:list-subscribe:list-unsubscribe :content-type:content-transfer-encoding; bh=9AlA0yl9/K+YUzX817vQBG1OiI2E8ax+NTOkyiqYDwk=; b=WOrwGOZi2jx6CuohKlN0uafUasMBIvsX0N49K9zDlj5R/zsvfmv2oXY5R+kZtAGDOH nLid9SUUjANt7gWKkUvxx5zQDmkRV3+YWkSNRUedCMix5RTfMKwDDoZ2DsawVBz+G9Z0 +CiyoA5IBrYRfih1otkLLW78c3TkOS8wCMRMs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlegroups.com; s=beta; h=x-beenthere:received-spf:mime-version:in-reply-to:references:from :date:message-id:subject:to:x-original-authentication-results :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:x-thread-url:x-message-url:sender :list-subscribe:list-unsubscribe:content-type :content-transfer-encoding; b=iqVHIyw5Y3rSqfk1Q6JuZKSZjcYQiiZLb+f3VOvTB/27oOsyRa+8AXOmv+3rM+z8RA ZrQwob3gZU6zhxgk2rhEm26ttUQYVEnpzL7cEbQ16oiRB5KzrQ8lnJCXUwSwvhkxNvpS miSxNvzax06t+k3cSs67SDutdAcC/M8ybt2uM= Received: by 10.224.5.209 with SMTP id 17mr126974qaw.2.1267972487171; Sun, 07 Mar 2010 06:34:47 -0800 (PST) X-BeenThere: rack-devel@googlegroups.com Received: by 10.224.81.20 with SMTP id v20ls2587895qak.5.p; Sun, 07 Mar 2010 06:34:45 -0800 (PST) Received: by 10.224.106.206 with SMTP id y14mr434871qao.10.1267972485557; Sun, 07 Mar 2010 06:34:45 -0800 (PST) Received: by 10.224.106.206 with SMTP id y14mr434870qao.10.1267972485529; Sun, 07 Mar 2010 06:34:45 -0800 (PST) Return-Path: Received: from qw-out-1920.google.com (qw-out-1920.google.com [74.125.92.149]) by gmr-mx.google.com with ESMTP id 25si408665qyk.15.2010.03.07.06.34.45; Sun, 07 Mar 2010 06:34:45 -0800 (PST) Received-SPF: pass (google.com: domain of headius@headius.com designates 74.125.92.149 as permitted sender) client-ip=74.125.92.149; Received: by qw-out-1920.google.com with SMTP id 5so1176627qwf.4 for ; Sun, 07 Mar 2010 06:34:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.23.145 with SMTP id r17mr1774674qab.119.1267972485216; Sun, 07 Mar 2010 06:34:45 -0800 (PST) In-Reply-To: <44f3f951-889e-45ec-ae46-40a371329a9e@e1g2000yqh.googlegroups.com> References: <20100306075548.GB6474@dcvr.yhbt.net> <44f3f951-889e-45ec-ae46-40a371329a9e@e1g2000yqh.googlegroups.com> From: Charles Oliver Nutter Date: Sun, 7 Mar 2010 08:34:25 -0600 Message-ID: Subject: Re: Not cleaning up tempfiles for multipart? To: rack-devel@googlegroups.com X-Original-Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of headius@headius.com designates 74.125.92.149 as permitted sender) smtp.mail=headius@headius.com X-Original-Sender: headius@headius.com Reply-To: rack-devel@googlegroups.com Precedence: list Mailing-list: list rack-devel@googlegroups.com; contact rack-devel+owners@googlegroups.com List-ID: List-Post: , List-Help: , List-Archive: X-Thread-Url: http://groups.google.com/group/rack-devel/t/6eb2bc7a1f8c072c X-Message-Url: http://groups.google.com/group/rack-devel/msg/ac042ecced0dbc4d Sender: rack-devel@googlegroups.com List-Subscribe: , List-Unsubscribe: , Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Mar 6, 2010 at 4:25 AM, Hongli Lai wrote: >> Why not? =C2=A0Tempfiles are objects, too. =C2=A0It's perfectly reasonab= le >> 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