Again, that's a file that seems to match up just fine with the SQL query we ran in comment 1.
Therefore, I'm left with exploring what the ProxyClientFactory is, and seeing if it might have anything to do with this (because I don't see that part of the log in devel); and then re-checking the SQL results.
Developments:
- qastaging is exhibiting the same behavior. (staging is dead because of a failed restore; I've investigated that separately.)
- The logging code is now in place. I can verify by seeing "Using upstream librarian http:// launchpadlibrar ian.net: 80" in the log output.
- The logging code indicates that the 404 is not caused by any of the problems I logged. It's the same as before.
2010-10-27 16:17:57+0000 [-] Starting factory <twisted. web.proxy. ProxyClientFact 2010-10- 27 16:17:57+0000 [ProxyClient, client] 91.189.90.174 - - [27/Oct/2010:16: tdGJABsFQRvCCFl FQFUZlZSJOd9. txt HTTP/1.0" 404 146 "- client] Stopping factory <twisted.web.prox ctory instance at 0x76c6560>
ory instance at 0x76c6560>
17:56 +0000] "GET /42395443/
" "Python-urllib/2.6"
2010-10-27 16:17:57+0000 [ProxyClient,
y.ProxyClientFa
Again, that's a file that seems to match up just fine with the SQL query we ran in comment 1.
Therefore, I'm left with exploring what the ProxyClientFactory is, and seeing if it might have anything to do with this (because I don't see that part of the log in devel); and then re-checking the SQL results.