[rt-users] SOLVED: temp directories and File::Temp problem

[Philip Kime]

Just for the record. I had the following problem:
 
I noticed that there were lots of temporary directories filling up /tmp
with random names on my RT 3.4.5 system. Names like those used by
File::Temp. Also lots of errors in syslog and apache error logs about
not being able to delete these directories because they weren't empty.
These directories are temporary disk storage for incoming emails into
RT. I eventually traced the problem to the readdir() function in
File::Path which was returning the right number of entries for the files
in these directories but with the empty string as their name. So the
unlink's were failing and the subsequent rmdir() was failing because the
files in the dirs were still there. A related problem was that the RT
OnlineDocs module doesn't work - the index of modules isn't built. I
didn't realise that they were the same problem at first. Well, it's a
known problem - this from the mod_perl troubleshooting guide:
 
----
If readdir() either fails with an exception, or in the list context it
returns the correct number of items but each item as an empty string,
you have a binary compatibility between mod_perl and Perl problem. Most
likely the two have been built against different glibc versions, which
have incompatible struct dirent.
 
To solve this problem rebuild mod_perl and Perl against the same glibc
version or get new binary packages built against the same glibc version.
----
 
This was my problem. It was horrible. Even the latest Activestate binary
Perl release is linked against the ancient glibc 2.1.3 wheras I built
mod_perl2 with glibc 2.3.4. I had to rebuild Perl from scratch,
including all of the RT required modules. Thank heavens for the CPAN
module. So, if you see odd readdir() behaviour that you can't reproduce
by just running the code in perl (this works - it's when it's run under
mod_perl that there is a problem), it's almost certainly this.
 
PK
 
--
Philip Kime
NOPS Systems Architect
310 401 0407
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20060421/8d28dba4/attachment.htm>