"Jeffrey Hartmann" <[EMAIL PROTECTED]> writes:
> 2). Apache::Upload seams to delete it's temp file, however when I run "df"
> the memory that file used is still allocated but there are no files in the
> /tmp dir. I've commented out all of the Image::Magick code in that block so
> that Image::Magick never uses or accesses the file and the allocated memory
> problem still exists. So this means that I end up with 100 meg of used
> space with only half that showing up as files in the dir. I can delete all
> the Image::Magick files in the dir, but that's only half of the space used.
>
> Now I used to use a normal /tmp dir for this, and I still had the
> Image::Magick problem, but I never noticed the Apache::Upload one until now.
> So I don't know if this problem exists without with tmpfs. Also if I
> restart/graceful Apache it seems to release the "disk space" that it's
> holding.
It sounds like the apreq????? file in /tmp is remove()d at the end of the
request, but the file somehow stays open until the process exits. Using
"lsof" or running a stack trace on "httpd -X" should tell you if this is
the case. The relevant cleanup code is the remove_tmpfile() function in
c/apache_request.c. If the ap_pfclose() call is failing, it should show
up in your apache logs.
If that's not the problem, maybe there's a persistent Apache::Upload
object somewhere in your code?
[...]
> foreach my $file (@upload)
> {
>
> my $i = Image::Magick->new(magick=>$type);
> $err = $i->ReadImage(file=>$$fh);
> $i->Set(magick=>$type);
> $err = $i->WriteImage(filename=>$filename));
> warn "$err" if "$err";
> undef $i;
> }
>
Try appending
undef @upload;
to make sure there are no Apache::Upload objects still floating
around when your handler exits.
HTH
--
Joe Schaefer
