So lets say there's a server process that takes way too long. The client complains that it "times out."
Correct me if I'm wrong, but this particular timeout could have to do with apache's timeout setting, but not necessarily. I believe this to be the case because when testing the page in question we couldn't get it to time out reliably - mostly the browser would just spin for as long as it took.
The timeout setting would come into effect if there were issues with the connection to the client, as described in the documentation. But if the connection was fine, it would be up to the client to close the connection (I believe).
I assumed this also meant that if the client closed their browser, Apache would hit the timeout limit (in my case, 300 seconds), and kill the process. This doesn't seem to be the case.
Here's how I tested it:
I added a while loop to some code on the server:
too_long = 2000
tstart = time.time()
f = open('/tmp/timeout_test.txt', 'w')
while True:
time.sleep(100)
elapsed = time.time() - tstart
f.write('Loop, %s elapsed\n' % elapsed)
if elapsed > too_long:
break
I then open the web page to launch that loop, and ran netstat on the server:
~$ netstat -np | grep ESTAB | grep apache
tcp 0 0 10.102.123.6:443 10.102.119.101:53519 ESTABLISHED 16534/apache2
tcp 0 0 127.0.0.1:60299 127.0.0.1:5432 ESTABLISHED 16534/apache2
(that's me at 10.102.119.101, the server is at 10.102.123.6)
I then closed my browser and reran that netstat line:
~% netstat -np | grep ESTAB | grep apache
tcp 0 0 127.0.0.1:60299 127.0.0.1:5432 ESTABLISHED 16534/apache2
My connection disappeared, but the server was still in the loop, I could confirm by running:
~% lsof | grep timeout
apache2 16534 www-data 14w REG 8,1 0 536533 /tmp/timeout_test.txt
meaning the apache process still had that file open. For the next 2000 seconds, when I ran:
~% cat /tmp/timeout_test.txt
I got nothing. After 2000 seconds the netcat line produced nothing at all, and the tmp file was filled out with the output from the while loop.
So it seems that Apache process just does what it was asked to do, regardless of the client connection? And what is that loopback connection about?