Mailing-List: contact apreq-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
To: apreq-dev@httpd.apache.org
Cc: modperl@perl.apache.org
Subject: Re: libapreq: could not create/open temp file
References: <3D0130BA.3050405@esoft.pf> <3D018BDF.4070303@stason.org>
From: Joe Schaefer <joe+apache@sunstarsys.com>
Date: 08 Jun 2002 07:40:00 -0400
In-Reply-To: Stas Bekman's message of "Sat, 08 Jun 2002 12:45:19 +0800"
Message-ID: <m3ptz20zjj.fsf@mumonkan.sunstarsys.com>
Lines: 30
User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.5
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii


> Jean-Denis Girard wrote:
> > 
> > Everything worked flawlesly, the web site was still working, but after a 
> > few days, visitors started to complain  that uplaods didn't work. 
> > mod_perl dies with the message:
> >     [libapreq] could not create/open temp file
> > What is really funny, is that it works after rebooting the system, and 
> > the error shows up later.

Where are the temp files being created, on a RAM disk or something?
pre 1.0 apreq's had a bug that caused filehandles to leak (there's
a refcount problem in the IO parts of perl's ExtUtils/typemap), which
would eventually fill up /tmp (this is the default location of your 
spooled apreqXXXX files) until apache was restarted.


> > I upgraded libapreq to 1.0, which didn't solve the problem. Next step 
> > will be to upgrade APache, mod_perl, etc. but I would like some help.

In 1.0, we no longer use perl's ExtUtils/typemap for this, which should
take care of the aforementioned leak.  One other possible candidate is 
that your apache server is segfaulting after the file is received, which 
prevents apache from cleaning up the temp files.  If so, you should see
a bunch of apreqXXXX files filling up your spool directory.

-- 
Joe Schaefer
joe@sunstarsys.com