Item10737: File::Temp with mod_perl can't create unique temporary files

When running Foswiki 1.1.3 on Apache 2.2.17 with mod_perl and ModPerlEngineContrib, trying to use the GenPDF plugin results in an error generating a temporary filename as follows:

| 2011-05-10T18:52:45Z warning | Error in tempfile() using /home/www/foswiki/working/tmp/GenPDFImgXXXXXXXXXXXX: Tried to get a new temp name different to the previous value 50 times.
Something wrong with template?? (/home/www/foswiki/working/tmp/GenPDFImgXXXXXXXXXXXX)

Testing my Perl configuration, the random number generator and File::Temp are working fine and produce random file names. However under mod_perl in Foswiki, the random part of the filename get's stuck at IIIIIIIIIII or CCCCCCCCCCCC.

A work-around immediately is to add the following line to the apache config to fix the handler for GenPDF to regular cgi:

<FilesMatch "^(genpdf)$">
   SetHandler cgi-script
</FilesMatch>

-- IridiumScaffold - 11 May 2011

Just encountered the same with the LatexModePlugin.

-- IridiumScaffold - 11 May 2011

Tracking this down, the problem with LatexModePlugin is unrelated. It would appear genpdf doesn't work properly with mod_perl (and possibly FastCGI as well).

The (possible) fix for LatexModePlugin was to install the libfile-temp-perl package under Ubuntu, which appears to allow the tempdir function in that plugin to operate correctly (I haven't got it fully working yet, but it seems to be a different error).

-- IridiumScaffold - 19 May 2011

On second analysis no, the libfile-temp-perl package simply provides a longer debug output from it.

-- IridiumScaffold - 20 May 2011

It's true we have too many 'Normal' priority bugs, but I don't think this one deserves to be 'Low'. Sounds serious to me, for mod_perl users of this plugin. I hope you don't mind, I've raised the priority to Normal.

-- PaulHarvey - 20 May 2011

A more general workaround for this problem, for the moment, appears to be adding a call to srand in mod_perl_startup.pl - right after the begin block I presently have:

srand (time ^ $$ ^ unpack "%L*", `ps axww | gzip -f`);

Results with this have been inconsistent though - sometimes after a while it stops working and the errors return.

-- IridiumScaffold - 21 May 2011

I've tried to recreate this on a Gentoo system - Apache 2.2.17 and mod_perl-2.0.4 and don't see any issues. DocumentGraphics should give sufficient number of temporary files.

The srand call (very linux specific) would probably be better done per request instead of once per mod_perl initialization. Maybe in Foswiki::Engine::Apache::run(). Given that the issue appears to be more related to File::Temp and ModPerlEngineContrib, I'll change the summary.

-- GeorgeClark - 22 May 2011

I've just been playing around with PerlPlugin to try and figure this one out with the following code:

%CODE% my($count) = 10; for ($count = 10; $count >= 1; $count--) { print "Random string is: ",join("",map{chr(int(rand(60))+64)}1..64),"\n\n"; } %ENDCODE%

This code would produce an output consisting of nothing but "P" for all entries, though refreshing the page continuously would sometimes produce proper random strings.

The best I can tell, this may have only been specific to this one server I've been running it on. I just rebooted it and so far things seem to be working - so it's possible there was some memory corruption, or something, which was persistently interfering with mod_perl across Apache restarts.

My second test Foswiki installation on my home server is not showing the error, but that get's rebooted fairly frequently for all sorts of reasons - I have some recollection it may have happened, but who knows.

I'll keep monitoring both and see if the problem re-emerges - and MemTest my host to make sure that's operating correctly. This whole thing has been very strange.

-- IridiumScaffold - 22 May 2011

And as of an hour or two later (after hammering the system with a memtest which found nothing) the problem is back!

Color me weirded out.

-- IridiumScaffold - 22 May 2011

So a new attempt at a work around: to my Apache configuration I've added:

PerlChildInitHandler "sub { srand }"

Which call's srand when a child is forked. We'll see in an hour or so if the problem resurfaces, since starting Apache should trigger a flurry of forks anyway. Why this happens on one system and not another is a mystery, and why nothing else involving rand on the system fails, or indeed using Perl outside of mod_perl, is also a mystery.

-- IridiumScaffold - 22 May 2011

So after a day or so of operation, my new solution failed. I've been following up the difference between my two servers: The Apache MPM I'm using is the different. The server which works is used apache-mpm-prefork, whereas the one which doesn't is using apache-mpm-worker (under Ubuntu).

torsten over at #modperl on irc.perl.org suggested that the solution above doesn't get called consistently per Perl interpreter, and that the following in my apache.conf should help:

PerlPostReadRequestHandler "sub {return 0 if $My::SRandCalled; $My::SRandCalled=1; srand ; return 0}"

I'll test it over the next few days, but it appears my random numbers are now working.

-- IridiumScaffold - 24 May 2011

It's worth noting that the solution above has been working superbly for me for the past year or so.

-- IridiumScaffold - 08 Jun 2012

Commenting is disabled while not logged in