Looks to me like chb is exactly right. And for this problem, strace is precisely the right tool, if you know how to read the output. If not, then as usual the granddaddy of all Swiss Army Intercontinental Ballistic Missiles would be the right tool (you may know it as "Google").

I am not Google, merely someone who can interpret strace output, so I'll break it down for you.

• Your script sends a GET request to some web server using file descriptor 9.
• It then waits up to three minutes (180 sec) for the response to come back on that file descriptor.
• The select call is interrupted by something, which generally means a signal.
• Sure enough, the next line shows a SIGTERM received.
• There were no intervening syscalls, so your script didn't send the signal to itself. Something else must have.

That something else is probably the web server, since it's generally the only thing that knows enough and cares enough about CGI processes to murder them. The next step is to look into its error log to see if it reported why it terminated your script -- but you did that and it didn't, which is kind of mysterious. Personally, I'd next strace the parent httpd of the script (run the script first, then attach to the parent you get in the process table with ps axf). But unless you're familiar with using strace output, that may just be a sure recipe for insanity.

I'll echo ropey's comment and ask why you're running this as a CGI?

As a last comment, try running
  strace perl -le '$v=""; vec($v,0,1)=1; select($v,undef,undef,180)'
in one window and then
  kill pid
in another (where pid is the pid of the perl script). You should see very familiar-looking strace output.