unix fastcgi server & stderr bug

Just a heads-up, this may be a known problem that more experienced FCGI 
developers are well versed in.

Using fcgi-2.4.0 on a Solaris machine (or Linux), we had the following bug.

An assertion failure in our fcgi server was scribbling the assertion 
failure message into a database file, corrupting it.

assert() writes to stderr (file descriptor 2), so we assumed that 
somehow, the database file was open on fd 2.

We hypothesised that when the fcgi client forked-and-execed the fcgi 
server program, the server was not redirecting stderr following the 
fork. This would mean that files opened by the server (such as the 
corrupted data file) might be assigned file descriptor 2.

Looking at OS_SpawnChild in libfcgi/os_unix.c, it clearly closes stdin, 
stdout and stderr.

We added a sleep() call to the fcgi server to pause it for debugging, 
then used lsof to see what files it had open. Descriptors 1 and 2 (stdin 
and stderr) were the socket file used to communicate with the fcgi 
client (as you would expect). However, fd 2 was indeed the database file.

So we've added some code in our fcgi server to make sure that fd 2 is 
redirected away (and are investigating that assertion failure!)


So -

Should the FastCGI library also tie stderr to the client, as it does 
stdin and stdout? Traditionally (with Apache at least) stderr ends up in 
the server logs, so it would be good to route stderr output back through 
the client.

I don't know what if anything the CGI standard says wrt stderr. If it 
does not say anything then the current behaviour would be better.


___________________________________
fastcgi-developers mailing list
http://fastcgi.com/fastcgi-developers/