中田さんお世話になります。
現在の所不具合は何もありません。
F5の連打もやってみましたが、アボートは記録されませんでした。
その後治まっているようですのでしばらく様子を見てみます。
メモリ使用量はMax54Mバイトまで増えて、現在は37Mバイトまで下がっています。
相宮さん、
errors.log が少し大きくなるという他に、何か動作上の不具合はありますか？
動作上の不具合がなければ、たとえ相手が「アタック」のつもりだとしても「アタック」にはなっていないのですから、放っておくのがよいと思います。
それでも、どうしてもどういうことなのか理解したいということでしたら、
CGIに自分でアクセスして適当な頻度で何回かリロードしてみてから errors.log を見てください。 F5を適当な頻度で押す、というのがよいでしょう。 F5 を押し続けてのキーリピートだと早すぎて、Warning: connection reset during Recv() in ClientRead() ... が続いてしまうと思います。もちろん、CGIが全部表示されてからリロードするのでは遅すぎますが。
中田さん、お世話になります。
エラーログが増殖している件ですが、土曜日から日曜日かけて以下のような内容のアボートが
休み無く2時間にわたってビッシリ記録されました。
こういった事はクライアントが意図して出来るものでしょうか？つまりこのようなアタックは
可能なのでしょうか？。何となく誰かに攻撃されているような気がするのですが・・。
また、アタックかどうかを調べる方法はありますでしょうか？。
よろしくお願いします。
Sat Sep 11 23:35:07 2004 Client Abort (or SOCKET_ERROR 10054) detected in processing Header 1 for Thread 132時間分のログは以下で確認できます。
Sat Sep 11 23:35:07 2004 Client Abort (or SOCKET_ERROR 10054) detected in processing Header 2 for Thread 13
Sat Sep 11 23:35:07 2004 Client Abort (or SOCKET_ERROR 10054) detected in processing Header 2 for Thread 13
Sat Sep 11 23:35:07 2004 Client Abort (or SOCKET_ERROR 10054) detected in processing Header 2 for Thread 13
Sat Sep 11 23:35:07 2004 Client Abort (or SOCKET_ERROR 10054) detected in processing Header 2 for Thread 13
Sat Sep 11 23:35:07 2004 Aborted in procHeader(3)
Sat Sep 11 23:35:07 2004 SOCKET_ERROR at terminating chunked transfer
相宮さん、
Warning: connection reset ... や Client Abort (or SOCKET_ERROR 10054) やそれに続く同時刻のメッセージは、通常アクセスしている側が、中止ボタンを押したり、違うページにジャンプしたということを示しているだけなので、動作上の「エラー」ではありません。
もちろん Error Response 40x ... や Info:... も動作上の「エラー」ではありません。
どちらかと言うとエラーログというのは情報提供用の補助のログなので、たくさんあっても「エラー」が多いとは思わない方がよいです。
ただし、ずっと出続けるとか、異常動作と対応しているということであれば、それは本当のエラーかもしれません。
中田さん、いとさん、山田さん他、お世話になります。
いとさん、確認しましたが、exe の「一般パスでも実行する」も「単一スレッド」にも
チェックはしてありませんでした。したがって圧縮ファイルの解凍途中の入力待ちでは
ないようです。
日付が変わってから今までのエラーログは以下のような感じです。
http://aimiya.jp/errors.txt
こんなに賑やかにエラーが発生していますが、普通のリクエストには正常に動作してます。
メモリ使用量は現在26Mバイトまで増加してきております。
どんなリクエストの時にエラーが発生しているのかもう少し調べてみます。
山田さん、相宮さん、中田さん
当方のサーバの errors.logを過去に遡って調べたところ、
Can't create file for stdout in spawnProcess.
が続く現象は 1年以上も前のことですが、唯一度だけ起きていました。
原因は恐らく違うでしょうが、何かヒントがあるかもしれないので
そのときの状況を推測を交えて書いてみます。
サーバの設定で、exe の「一般パスでも実行する」にチェックし、
「単一スレッド」にもチェックをしていた。そのためダウンロード
させるつもりの exeファイルにアクセスがあったときにサーバ上で
自己解凍が始まり、入力待ちで放置状態になった。
アクセスした人は応答がないのでブラウザから「中止」したか、
他のページにアクセスし直したが、解凍のプロセスはサーバ上に
残ったままになり、その後 SSIやCGIにアクセスがある度に
上記のメッセージが出続けていた。
「Client Abort」はアクセスを中止(あるいは移動)した時に出ます。
「Can't create file …」が続くのは SSIにアクセスがあったから
(CGIでは「Error Response 500 …」も出る)ですが、問題なのは
その SSI/CGIではなく、その前に Abort になった方だと思います。
サーバ上で該当するプロセスを調べて殺さないと AN HTTPDを
再起動させても「サーバソケットを使用出来ません。
他のサーバが動いていないか確認してください」となり
起動に失敗します。結局よく分からないと Windowsを
再起動するという対応をせざるを得なくなると思います。
上記のケースであれば、一応以下の解決策が考えられます。
1. 「一般パスでも実行する」のチェックを外し、
ダウンロードさせる exeファイルは必ず一般パスに置く
2. exeの CGIを使わないなら exeの「実行する」のチェックを
外すか CGIの exe行自体を削除する。
3.「単一スレッド」のチェックを外す
残ってしまうプロセスは exe とは限らないので、より一般的には
3. が最善の策かと思われます。
「単一スレッド」については以下のコメントで書いた問題もあり、
http://homepage1.nifty.com/yito/namazu/gbook/20040713.2054.html
チェックを外すのがいいのではというのが私の考えです。
もし「単一スレッド」にチェックはしていないということであれば
全く別の話と思われるので、チェックの有無をお知らせください。
相宮さん、
何かわかりましたら、お知らせください。
Anhttpdを快適に使わせて頂いております。OSはWin2000です。
最近一部のCGIが動作しなくなる現象が発生するようになりましたので調べております。
CGIが動作しなくなった場合はAnhttpdの再起動で復旧しております。
ここのログにある現象を確認しましたところ、CGIが動作しなくなることに関係するのか
どうかは分かりませんが、メモリの増加が確認されました。起動時は6M弱のものが
8時間後には15Mバイトに増えていました。ということで
> いとさん 2004/08/01 14:36
> Windows2000ではこの現象はみられません。
は、うちでは発生しています。どこまで増えて行くのか観察中です。
最近変わったことと言えば、SSIでファイル更新日付を表示させるようにしたことがあります
ので、それが関係するかとエラーログを取り見たところ。
> 山田さん 2004/09/09 04:54と同じ内容のログが連続して見られました。
> Thu Sep 09 04:43:29 2004 Client Abort 1-- detected during CGI/SSI process
> Thu Sep 09 04:43:30 2004 Warning: Connection closed and CGI process ID=336 still alive
> Thu Sep 09 04:43:30 2004 Information: CGI process ID=336 finished
> Thu Sep 09 04:43:30 2004 Client Abort detected during CGI/SSI process
> Thu Sep 09 04:43:44 2004 Can't create file for stdout in spawnProcess.