Apache日誌出現internal dummy connection信息

　　羣集裏多個web站點的Apache日誌合併出現問題。
　　將原來分散的web應用整合成羣集後，同一個站點產生的多個日誌需要進行合併。其中一個站點在合併apache日誌的時候總是報錯，爲了搞清楚原因仔細看了該站點和其他站點日誌有何不同，結果發現在不能合併的日誌中發現大量的internal dummy connection信息。

::1 - - [01/Nov/2008:00:01:04 +0800] "GET / HTTP/1.0" 200 95536 "-" "Apache/2.2.0 (Unix) PHP/5.2.3 (internal dummy connection)"
::1 - - [01/Nov/2008:00:01:05 +0800] "GET / HTTP/1.0" 200 95536 "-" "Apache/2.2.0 (Unix) PHP/5.2.3 (internal dummy connection)"
::1 - - [01/Nov/2008:00:01:06 +0800] "GET / HTTP/1.0" 200 95536 "-" "Apache/2.2.0 (Unix) PHP/5.2.3 (internal dummy connection)"
::1 - - [01/Nov/2008:00:01:07 +0800] "GET / HTTP/1.0" 200 95536 "-" "Apache/2.2.0 (Unix) PHP/5.2.3 (internal dummy connection)"
::1 - - [01/Nov/2008:00:01:08 +0800] "GET / HTTP/1.0" 200 95536 "-" "Apache/2.2.0 (Unix) PHP/5.2.3 (internal dummy connection)"
::1 - - [01/Nov/2008:00:01:09 +0800] "GET / HTTP/1.0" 200 95536 "-" "Apache/2.2.0 (Unix) PHP/5.2.3 (internal dummy connection)"
::1 - - [01/Nov/2008:00:01:10 +0800] "GET / HTTP/1.0" 200 95536 "-" "Apache/2.2.0 (Unix) PHP/5.2.3 (internal dummy connection)"
::1 - - [01/Nov/2008:00:01:11 +0800] "GET / HTTP/1.0" 200 95536 "-" "Apache/2.2.0 (Unix) PHP/5.2.3 (internal dummy connection)"

　　把這些包含internal dummy connection的行從日誌中清除後日志可以正常合併，看來問題就出在這些被記錄在Apache日誌中的internal dummy connection信息了。但是這些信息總不能每個都要手工清除吧，分析日誌總歸還是要做成自動化。要在日誌中屏蔽這些信息可以通過修改Apache配置文件實現，

SetEnvIf Remote_Addr "::1" dontlog
CustomLog "|/usr/local/sbin/cronolog /www/logs/XXX/access%Y%m%d.log" combined env=!dontlog

　　修改配置文件之後產生的Apache日誌屏蔽了這些信息，表面上日誌中不再記錄這些內部進程的通信，但是這並不代表問題不存在。那深究一下同樣的環境下，爲什麼這些信息只出現在一個站點上而其他站點沒有類似的問題？又爲什麼會產生這些信息呢？
這些信息是爲了方便管理員在日誌中查找出錯誤的請求

/* Create the request string. We include a User-Agent so that
* adminstrators can track down the cause of the odd-looking
* requests in their logs.
*/
srequest = apr_pstrcat(p, "GET / HTTP/1.0\r\nUser-Agent: ",
ap_get_server_version(),
" (internal dummy connection)\r\n\r\n", NULL);

internal dummy connection的產生是因爲apache的MPM模塊用prefork方式工作，而用worker MPM則不會使用pipe of death在進程間通信，也就不會有internal dummy connections的問題。

It's defined in /server/mpm_common.c:

| This function connects to the server, then immediately closes the
| connection.
| This permits the MPM to skip the poll when there is only one listening
| socket, because it provides a alternate way to unblock an accept()
| when the pod is used.

pod=pipe of death.

| The pipe of death is used to tell all child processes that it is time
| to die gracefully.

So if you use the worker MPM which doesn't use a pod, there are no
internal dummy connections anymore.

現在搞不清楚爲什麼只有N多站點中只有一個站點出現這樣的問題，如果找到原因我會續上。有朋友知道也請指點。