[rt-devel] Temporary Files

[Jeff Sheltren]

Hi, I have also experienced this, so I am glad to finally see a patch! 
Thank you very much.

By the way, there were a couple previous discussions of this, not sure
why your search didn't turn up any.  Here's one:
http://lists.fsck.com/pipermail/rt-users/2003-June/014787.html

But I'd much rather have RT clean up after itself than have to run a
cron job to clean up /tmp! :)

-Jeff

On Mon, 2004-03-08 at 22:32, Jonathon Padfield wrote:
> Firstly, I'm no expert in RT, I just got picked to look into why one of our 
> servers running RT was slowing down.
> 
> One of the issues is that the /tmp directory is filling up with temporary 
> files and directories.
> 
> I believe that the problem exists in the lib/RT/Interface/Web.pm module. The 
> temporary file created has no unlink associated with it, and tempfile() is 
> called in such a manner to prevent the file being automatically deleted on 
> program exit or file closure.
> 
> I've written a small patch, but would appreciate somebody who's more 
> experienced with the code to verify that the patch shouldn't break anything.
> 
> *** Web.pm      2003-09-26 06:31:07.000000000 +1000
> --- Web.modded.pm       2004-03-09 16:05:36.000000000 +1100
> ***************
> *** 523,529 ****
>           # on NFS and NTFS, it is possible that tempfile() conflicts
>           # with other processes, causing a race condition. we try to
>           # accommodate this by pausing and retrying.
> !         last if ($fh, $temp_file) = eval { tempfile() };
>           sleep 1;
>       }
> 
> --- 523,529 ----
>           # on NFS and NTFS, it is possible that tempfile() conflicts
>           # with other processes, causing a race condition. we try to
>           # accommodate this by pausing and retrying.
> !         last if ($fh, $temp_file) = eval { tempfile(UNLINK => 1) };
>           sleep 1;
>       }
> 
> Secondly, I searched the archives, but didn't see any mention of this 
> recently. Unfortunatly the server lists.bestpractical.com is listed in SPEWS 
> again.
> 
> 
> Regards,
> 		Jonathon Padfield