[Melbourne-pm] An intermittent problem with open for append

[Mathew Robertson]

>> I've got a CGI program that has a problem every once in a while.
>>
>> The problem code looks like:
>>
>> open OUT,">>/home/foo/que/$ip" || push @error, "Cant save details";
>> print OUT "$ip:t:date=",scalar localtime,"\n";
>> ... then it prints to OUT all the rest of ${ENV} and CGI vars.
>>
>> Sometimes apache will record 2 hits on the page (a double click?)
>> and most of the time I get two sets of all the data however sometimes
>> while running perl 5.8.8 I only get the first or second sometimes.
>> This never happens with perl 5.005_02.
>>
>> Can anyone explain why perl 5.005 works yet 5.8.8 doesn't?
>> I was under the impresson that the ">>" means tell the OS to
>> open in append mode, any data written should go in the file
>> and not just end up lost.
>>     
>
> I can't explain why it works on 5.005 and not 5.8.8, but since you have
> mentioned it is a very rare occurence, it is possible that it /would/ occur on
> 5.005 eventually. Maybe the code just runs slower or faster and flukily avoids
> a race condition as a result?
>
> Also, it's worth noting that append isn't always safe for use by multiple
> processes - it works by seeking to the end of the file before writing, but
> according to the man page, this doesn't work reliably on networked file systems
> like NFS.
>   
I suspect this is root of the problem, irrespective of NFS -> the 
webserver is using two instances of the script, to execute the request.

If two processes open the same file for append, they will both succeed.  
Both processes will move their file pointer to the "end of the file" - 
which both happens to be at the same byte offset. One starts 
"print"ing... then the other "print"s -> the second write will clobber 
the first write.

This applies to both mod_perl and CGI environments.  If you want 
cooperative access to a "shared resource, aka the $ip file, then you 
need locking (or something similar).

> Also - I think Apache will send a signal to the CGIs running, to kill them if
> the connection dies - is it is simply a case that when someone double-clicked,
> one of the cgi instances was killed before it could write to the logfile
>   

regards,
Mathew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.pm.org/pipermail/melbourne-pm/attachments/20080528/264862f4/attachment.html