|目次|手順 0|1|2|3|A|B|C|D|E|F|G|H| I |J|K|L|M|N|O|P|Q|
作成日:2003年01月26日、更新日:2004年11月21日 作成:鷹の巣インターネット用WWWサーバーのセキュリティと応答速度を意識した設定例をAN HTTPDを例に説明します。
設定の方針は、
目次
このページでは、下表に示します様なフォルダの配置を行なって、説明します。CGIが実行可能なフォルダ(実行パス)は、限定します。この実行パス以外のフォルダにCGIファイルが設置された場合、CGIファイルは、実行されずにソースリストが表示されます。(ブラウザ側で、ファイルの拡張子による関連付けがない場合は、ダウンロードとなります。)
| 番号 | WebページのURL(URI) | 主たるファイルのローカルパス |
|---|---|---|
| 1 | (AN HTTPDをD:\www\httpdにインストール) | D:\www\httpd\httpd.exe 注)1 |
| 2 | (Active PerlをD:\Perlにインストール) | D:\Perl\bin\perl.exe 注)1 |
| 3 | http://www.example.com/index.html | D:\www\public_html\index.html |
| 4 | http://www.example.com/cgi/samle.cgi | D:\www\cgi-bin\samle.cgi 注)2 |
| 5 | http://www.example.com/~user/index.html | D:\www\public_html\user\public_html\index.html |
| 6 | http://www.example.com/~user/cgi/sample.cgi | D:\www\public_html\user\cgi-bin\samle.cgi |
| 7 | http://www.example.com/~taro/index.html | D:\www\public_html\taro\public_html\index.html |
| 8 | http://www.example.com/~taro/cgi/samle.cgi | D:\www\public_html\taro\cgi-bin\sample.cgi |
フォルダ名には、空白を含まない半角英数字を使用すること。セーフモードで起動しても確実にフォルダ名が表示される様にするためです。
ここのCGI実行パスは、「 ~ 」(チルダ)を含みませんが、エイリアス名(別名)です。実際のフォルダ配置は、ドキュメントルート下のcgiというフォルダには、セキュリティ上、配置しません。
エイリアス名(別名)とは、「あだな」のことで、長いURLパスを短く表現するために使用しますが、実際のフォルダ配置をわかり難くするというセキュリティ上の利点があります。
例)真田左衛門佐幸村(さなださえもんのすけゆきむら=真田少佐幸村)のことを「ゆきちゃん」と言うような感覚です。
厳密に言いますと、間違いですが、以下、HTMLファイルを設置するhttpのドキュメントルート以下のフォルダのことを「一般パス」と言い、CGIファイルを設置するCGIのドキュメントルート以下のフォルダのことを「実行パス」と言うことにします。
以下の設定図は、比較のためにインストール直後の状態(赤色表示なし)と変更後の状態(赤色表示あり)を示しています。ページが重くなりましたが、ご容赦願います。
基本的にドキュメントルートは、システムドライブのCドライブ以外に設定します。(セキュリティ上とバックアップの利便性上)
「リモートホストを取得」は、「取得しない」を選択したままです。(処理速度の向上。これは、CGI側でも必要に応じて、処理出来ます。)
「常時」を選択しますと、ログファイルにIPアドレスではなくホスト名が記録される様になりますが、IPアドレスの逆引きに時間が掛かり、httpdの応答が悪くなります。不正アクセスなどのIPアドレスは、何時でもホスト名に逆引き出来ます。ただし、あまり信用できない環境変数のREMOTE_HOSTをCGIやSSIで使用する場合は、「CGI/SSIでは取得」を選択します。
CGIのみの使用では、「SSIを許可する」のチェックをはずします。(処理速度の向上。セキュリティ上。)
拡張子に「.log」を追加。(セキュリティ上)
CGIによっては、その設置のしやすさを優先している場合に、実行パス下のログファイルがURL指定で、そのまま閲覧できるものがあります。ここに設定することにより、Perl.exeからログファイルが実行されますので、ブラウザではエラー表示となって閲覧できなくなります。ログファイルのファイル名の拡張子を「.log」より「.cgi」に変更することと同じ効果があります。
実行プログラム欄のperl.exeは、絶対パスで書きましょう。(気分的な処理速度の向上。AN HTTPDの場合のみ)
CGIで、ログファイル名を指定する場合に、「$logfile = 'data.log';」と書かずに「$logfile = './data.log';」と書いているのを見たことがあると思います。これは、ファイル名の先頭に「./」が書かれている場合、確実に現在のディレクトリ下のファイルだけを対象にするためです。これに対し、「./」が書かれていない場合は、環境変数PATH以下のファイルも検索対象になり、予期しないファイルが対象になったりします。
ここにPerlとだけ書いている場合は、OSが環境変数PATHを調べてから、Perl.exeを絶対パスにしてから実行しますので、無駄な動作を行っていることになります。
拡張子欄がCGI(Perl)の行で、「般」の欄のチェックは、はずします。(セキュリティ上、実行パス下だけCGIの実行を許可します。)
逆に、一般パスにCGIのファイルを設置すると、実行されずにソースが丸見えとなります。実行パスは、エイリアス表記で、実際のフォルダ配置とは違った表記ができるのですから、CGIなどの実行ファイルは、実行パス下に設置しましょう。ただし、インターネット上の第三者のFTPクライアントから、自宅WWWサーバーの実行パス下にCGIファイルのFTPアップロードを許している場合は、CGIファイルに書かれた任意のコマンドが実行できるというセキュリティ上、甚大な問題が生じる恐れがあります。
拡張子の「.exe」や「.bat」や「.dll」のチェックは、はずしhttpdから実行不可能にします。(セキュリティ上。AN HTTPDの場合のみ)
もし、検索エンジンのnamazu.cgi.exeなどを導入する場合は、拡張子の「.exe」のチェックを入れる必要があります。しかし、私はこのファイル名をnamazu.ccgiに変更して、拡張子をexe以外にし、拡張子欄に「.ccgi」を登録し、実行プログラムを「--self--」として、直接実行可能にすることにしています。拡張子を「.cgi」にしても良いのですが、他のCGIファイルと識別するために実行ファイルかどうかをチェックする必要(EX欄にチェック)が生じ無駄です。従って、WWWサーバー上から、実行する実行ファイルの拡張子「.exe」を「.ccgi」として明からに区別することをお薦めします。


「表示」グループの「動作表示」の「インジケータ」のチェックは、はずします。(気分的な処理速度の向上。AN HTTPDの場合のみ)
これを実施すると、アクセスがあってもhttpdアイコンに稲妻が光らなくなります。(WWWサーバーの試験時には、チェックが必要かも知れません。)
「インデックス」グループの「インデックスリスト(ディレクトリリスト)を表示」のチェックは、はずします。(気分的な処理速度の向上とセキュリティ上。AN HTTPDの場合のみ)
これを行うとURLがディレクトリ指定の場合、「.www_browsable」ファイルを探さなくなります。膨大なファイルのファイルリストを表示する場合で、保守が面倒な場合を除いて、この機能は使用しないくても良いはずです。
「メッセージ」グループの「サーバー名/バージョンをエラーメッセージ/インデックスリストで表示」のチェックは、はずします。(気分的な処理速度の向上とセキュリティ上)
しかし、httpd応答ヘッダには、サーバー名とそのバージョンが書いてありますので、過信は禁物です。
(2004.07.02 追記)「メッセージ」グループの「エラー401~500」のチェックを入れるとWebサーバーのエラーメッセージをWebサーバー用エラーメッセージ(故障表示)ファイル例の様な自サイト独自の表示に変更できます。

(2004.07.02 追記)拡張子がtxt,textの行のMIMEタイプtext/plainに使用している文字コードを追加します。使用している文字コードがShift_JISの場合は、下図の様に拡張子がtxt,textの行のMIMEタイプをtext/plainから、text/plain;charset=Shift_JISに変更します。 この変更を行いますと、http://www.example.com/sample.txtのようにアクセスして、テキストファイルを表示する場合、http応答ヘッダに文字コードを付加することが出来、ブラウザでの文字化け対策に大変有効です。
この様に設定して、Server Header Checkerのサイトからアクセスすると、Content-Typeがtext/html;charset=Shift_JISになっていることが確認出来ます。

無圧縮GIFの作成方法によると、ブラウザがNN 4.06以降かWindowsのIE 4.0以降の場合は、HTTP /1.1に対応していて、gzip圧縮に対応している様です。従って、Webサーバーで、内容をgzip圧縮して送信した方が、送出するデータ量が半減するため、応答性が上がります。 サーバーに多少負担が掛かりますが、下図の様に「可能な限りgzipで応答する」にチェックを入れます。ここにチェックを入れると一度だけですが、AN HTTPDが落ちたことがあったので、現在、私はチェックを入れていませんが、試して見る価値はあります。2004年06月13日よりチェックを入れています。「コンテント ネゴシエーションを有効にする」にチェックを入れるとAN HTTPD 1.42hが落ちることは、いとさんによってご報告されています。
尚、CGIやSSI等の動的なファイル出力の場合には、対応していないということなので、必要であれば、CGIやSSI側で対応することになります。この方法については、おまけ(perlスクリプトの気分的な速度向上他)に記載しています。


用途に応じて、設定を行います。現在の日本国内のIPアドレスは、JPNICが逆引きの管理を行っているIPv4アドレス一覧(2003年3月12日現在)とJPNIC管理下でAPNICが逆引きの管理を行っているIPv4アドレス一覧(2005年11月08日現在)になっています。
尚、このタブの表現は、許可IPや拒否IPになっていますが、IPというのは、IPアドレスの意味で、ホスト名もワイルドカードを使用して、入力できるようです。
何か解りませんでしたが、「同一ファイルへの同時アクセス数を制限する」のチェックは、はずしました。

追記形のログファイルは、メモリリークへの心配があるので、ログ更新は、一応「毎日」を選択して、細切れにしました。(処理時間の向上。)
ログファイルが巨大化すると、WWWサーバーのハンドルのバッファからログファイルに書き出される時に処理時間が多少かかったり、実メモリの圧迫要因となったりしますので、ログファイルの大きさは極力小さくしましょう。毎月のログファイルに直す場合は、以下の様な内容のlog.batというバッチファイルをログファイルのフォルダ内に設置して実行すると、容易に連結できます。
echo ログのフォルダ内の毎日作成されたログファイルを1つにまとめます。 > log.txt FOR %%N IN (httpd.*.log) DO type %%N >> log.txt
また、連結しなくても、ある程度の複数ファイルの処理が下例のようなバッチファイルを使用すれば可能になります。
以下の様な内容のLogGoogle.batというバッチファイルをログファイルのフォルダ内に設置して実行する。
echo ログのフォルダ内の毎日作成されたログファイルから216.239.を含む文字列を1つのログファイルにまとめます。 > 216-239log.txt FOR %%N IN (httpd.*.log) DO find "216.239." %%N >> 216-239log.txt
すると、IPアドレスに「216.239.」を含む行がすべて抽出され、216-239log.txtに書き出される。
注)IPアドレスの逆引きホスト名が、crawl*.googlebot.comでないものは除外する必要があります。
好みで、「参照先」(アクセス元URL)や「ユーザエージェント」(WWWクライアントの種類)のログを取る様にチェックを入れます。(気分的な処理速度の低下、ただしSSIでユーザエージェントを収集するよりも処理速度は向上します。)
私としては、アクセス解析をCGIで行なわず、ここにチェックを入れ、AN HTTPD用アクセス解析ソフト(AWstats)設定例に示しています様にオフラインで、静的なhtmlファイルを作成して、アクセス解析されることを推奨します。
尚、CGIで「参照先」や「ユーザエージェント」の収集を実施している場合は、チェックを入れない様にします。(気分的な処理速度の向上)

Webサーバーのdebug目的で、trace.logにチェックを入れている場合には、注意が必要です。trace.logは、そのまま使用していますと、膨大なサイズになります。私のサイトでは、trace.logが5分間で1.5MBにもなります。従って、私はtrace.logを実施する場合、以下に示します様なperlスクリプトをいつも実行して、ログファイルのサイズを制限しています。
ログファイル(trace.log)のサイズを約1MByteに抑えるperlスクリプト例
#!/usr/local/bin/perl
#!D:/Perl/bin/perl.exe
# trace.logのサイズを約1MByteに抑える
print "trace.logのサイズを1MByteに抑えています。\n";
while () { # 無限ループ
# trace.logが500KBを超えて、古いファイル名が存在したら、ファイル名を変える。
if ( ( -s "trace.log" ) > 500000 ) {
# 古いファイル名が存在したら、古いファイルを削除する。
if ( -e "trace.old.log" ) { unlink( "trace.old.log" ); }
while () { # 無限ループ
# trace.logを古いファイル名(trace.old.log)に変える。
if ( rename ( "trace.log" , "trace.old.log" ) ) { last; }
# 1秒間処理を休む。
sleep (1);
}
}
# 60秒間処理を休む。
sleep (60);
}
exit;


一般にCGIが実行可能な実行パス下には、第三者によるFTPなどによる任意のファイルのアップロードは、出来なくします。 また、SSIが実行可能な状況では、一般パス下にも、第三者によるFTPなどによる任意のHTMLファイルのアップロードは、出来なくします。 これは、セキュリティ上、大変重要なことです。詳細は、「自宅サーバーのWebページスペースレンタル(貸し出し)について」を参照願います。ここでは、ApacheのsuEXECによく似ている機能であるAN HTTPDの「CGI動作アカウント」の簡単な設定方法について述べます。以下の設定は、私の頭の中で考えただけで、実施した実績は全くありません。(極めて無責任で申し訳ありません。)うまく設定できたり不具合が発生しましたら、掲示板に結果のご報告をお願い致します。
CGI動作アカウントのユーザ名をSYSTEM権限ではなく、CGI用の適当なユーザー名CGIuser(上図の例では、n4dG9wM3b6L82jWqdIer)として動作させ、CGIからアクセスできるフォルダやコマンドを制限する方法を以下に示します。 これは、全く信用のおけない息子のtaroに自宅サーバーのWebスペースを貸し出し、CGIの実行を許可することを想定してみました。

上記のWebサーバーの設定が終わりましたら、Webサーバー機のブラウザのアドレス欄にhttp://127.0.0.1/と入力して、ホームページ(トップページ)が表示されることを確認します。
ホームページ(トップページ)から、リンクしている掲示板などのCGIを動作させ、CGIの試験を行います。
動作が正常であれば、デスクトップより「スタート」-「ファイル名を指定して実行(R)」から、「regedit.exe」を入力し、レジストリ エディタを起動します。
マイコンピュータ\HKEY_LOCAL_MACHINE\SOFTWARE\AnHttpdを選択して、このフォルダ以下のレジストリを書き出し、フロッピーディスケットなどに格納します。ファイル名は、ANHTTPDXXXXyyyymmdd.reg(XXXXは、バージョンでyyyy年mm月dd日)の様にします。
今後は、上記のレジストリのフォルダを一旦削除してから、このファイルを(ダブル)クリックすると、レジストリをAN HTTPDの設定直後の状態に戻すことが出来るようになります。
項10の「ログ」タブの設定で、「ログ更新」を「毎日」に設定し、「参照先」(アクセス元URL)のログを取る様にチェックを入れている場合は、このログデータから、色んなことがわかります。
Windows用のActive Perl 5.6.1.633 built for MSWin32-x86-multi-threadに「Windows用Jcode.pmのインストール方法」で、jcode.pm ver.0.82をインストールし、下記のPerlスクリプトを使用すれば、必要なデータが整理できます。尚、Active Perl 5.8では、このモジュールに替わるEncodeモジュールが標準で組み込まれましたので、このバージョン以降は、jcode.pmをインストールする必要は、ありません。ただし、現状のバージョンでは、読み込むデータの文字コードの自動認識に失敗し、生成されるデータ数が若干少なくなります。
私の作成した「AN HTTPD用refererファイル解析Perlスクリプト(jcode.pmやEncodeモジュール使用)」を使用すると、下記の様な内容のアクセス頻度順がわかります。
以下に、このスクリプトから、生成されたデータの内容を示します。ちょっと不親切ですが、左側の数値は、出現頻度を示しています。例えば、200302RefererFromU.logの内容の一番上のデータは、GoogleのサーチエンジンのURLから、10日間で9364回アクセスがあったことを表わしています。
実は、私はこれだけで、アクセス解析を行っています。円グラフや棒グラフにしたければ、Excelなどに区切り符号を「スペース」にすれば、頻度とそのデータを読み込むことが出来ます。ほとんどの前処理を行っていますので、Excelでデータ処理する手間も省けるはずです。というよりは、私はこのスクリプトを使用するようになって、Excelを使用しなくなりました。
200302RefererFromU.logの内容例(2003年2月1日~10日の上位5位のみ抜粋)
9364 http://www.google.co.jp/search 5710 http://websearch.yahoo.co.jp/bin/query 4579 http://www.google.com/search 1031 http://www.minidns.net/home.php 855 http://search.yahoo.co.jp/bin/search
一番上のデータは、GoogleのサーチエンジンのURLから、10日間で9364回アクセスがあったことを表わしています。
200302RefererFromH.logの内容例(2003年2月1日~10日の上位5位のみ抜粋)
9367 www.google.co.jp 5710 websearch.yahoo.co.jp 4588 www.google.com 1034 www.minidns.net 868 search.yahoo.co.jp
一番上のデータは、ホスト名がGoogleのサイトから、10日間で9367回アクセスがあったことを表わしています。
200302RefererKeyS.logの内容例(2003年2月1日~10日の上位5位のみ抜粋)
789 自宅サーバー 568 鷹の巣 297 nslookup 276 自宅サーバ 177 minidns 143 プロキシサーバー
一番上のデータは、サーチエンジンから、「自宅サーバー」という検索キーで、10日間で789回検索されたことを表わしています。
200302RefererKeyW.logの内容例(2003年2月1日~10日の上位5位のみ抜粋)
1363 windows 1218 自宅サーバー 1212 設定 998 ftp 810 xp
一番上のデータは、サーチエンジンから、検索キーで「windows」という単語が、10日間で1363回使用されて検索されたことを表わしています。
200302RefererTo.logの内容例(2003年2月1日~10日の上位5位のみ抜粋)
4725 / 1572 /Router.html 1270 /SetminiDNSjp.html 591 /nslookup.html 462 /SetWinXPnet.html
一番上のデータは、アクセス元が判明しているアクセス(自サイトで最初にアクセスされたWebページ)で、自サイトのトップページが、10日間で4725回アクセスがあったことを表わしています。このアクセス回数には、ブックマーク(お気に入り)のアクセス回数は、含まれません。
ホームページ(トップページ)に設置のカウンタをテキストカウンタに
カウンタの方式ですが、トップページだけは、SSIを許可してSSI式のテキストカウンタを使用されることを推奨します。詳細は、「自宅サーバー用カウンタとアクセス解析CGIの総合改造例」をご参照願います。
汎用的なCGIの無駄な処理回路を削除したり、CGIのコメントを自動削除する。
詳細は、「自宅サーバー用カウンタとアクセス解析CGIの総合改造例」の「改造後の処置」をご参照願います。配布スクリプトの変更箇所が知りたい場合、「ファイル比較 phUpdate(Windows95/98/Me/ユーティリティ)」を使用すると便利です。
CGIコメントの自動削除には、質問W200.Perlソースリストのコメントをperlを使用して削除するには?のperlスクリプトを利用しています。
CGI(Perl)の動的なファイル出力側で、gzip圧縮に対応する。
CGI(Perl)の動的なファイル出力側で、gzip圧縮に対応するには、Windows用gzip.exeの入手先で、gzip圧縮の実行ファイルを入手します。また、gzip圧縮送信に関する てくにっく(スクリプトの配布元)を参考にCGIスクリプトを改造します。 「無圧縮GIFの作成方法」の中のgzipで圧縮も参考にして、以下に簡単なPerlのスクリプトを作ってみました。
#!D:/Perl/bin/perl.exe
# CGIでのgzip圧縮の試験 2003.10.26 鷹の巣
# gzip.exeの入手先 http://www.gzip.org/gzip124xN.zip
# 解凍後、D:\WWW\himitsu\binary\gzip.exeにコピーして設置する。
# 参考サイト(スクリプトの配布元)
# http://www.ibport.ne.jp/~yui/cgiwork/tech/src/gzip_cgi.txt
# http://www.oersted.co.jp/~emk/dhtml/nocompgif.html#gzip
$| = 1; # バッファリングしない。
if ( $ENV{'HTTP_ACCEPT_ENCODING'} =~ /gzip/ ){
print "Content-type: text/html\n";
if ( $ENV{'HTTP_ACCEPT_ENCODING'} =~ /x-gzip/ ){
print "Content-encoding: x-gzip\n\n";
} else {
print "Content-encoding: gzip\n\n";
}
# gzip.exeの引数の1 は、圧縮レベルで1(低圧縮)~9(高圧縮)、c は、圧縮結果を標準出力
open ( STDOUT , "| D:/WWW/bin/gzip/gzip.exe -1 -c" );
} else {
print "Content-type: text/html\n\n";
}
# この行以降の出力がgzip圧縮されて、ブラウザに出力されます。
if( $ENV{'HTTP_ACCEPT_ENCODING'} =~ /gzip/ ){
print "ブラウザがNN 4.06以降/WindowsのIE 4.0以降のため、gzip圧縮して送信中。\n";
} else {
print "ブラウザがNN 4.06以前/WindowsのIE 4.0以前のため、gzip圧縮せずに送信中。\n";
}
# 一応書いておこうっと。
$| = 0; # バッファリングする。
close ( STDOUT );
exit;
これまでの運用経過
このサイトでは、500Error(Internal Server Error:内部サーバー異常)が良く発生していました。その結果、バージョン1.42nでも他人のクッキーデーターが表示されるという事態に陥りました。 そこで、SSIを全てWebページから撤去すると、今のところError500は発生頻度は極めて少なくなりましたが、CGIだけでも発生することがありました。
2004年10月は、主としてホームページが、69745ページビューで、ツリー式掲示板が44059ページビューでした。
SSIの撤去前は、ホームページに検索エンジンの検索文字を引き継ぐ方法等があり、
<input type="text" name="query" size="30" value='<!--#exec cgi="/cgi/GetSearchWord.cgi" -->' />が1個
<input type="text" name="ipd" size="50" value='<!--#echo var="REMOTE_ADDR"-->' />が2個
ありました。
perlのゾンビプロセス(Zombie process)の発生と500Errorの関係
500Errorが発生した状態で、Windowsタスクマネージャのプロセスタブで見るとperlのプロセスが残っており、CPU時間が0でした。WindowsやAN HTTPDを再起動せずにこれらのゾンビプロセスを依存関係(親子関係)を無視して、タスクマネージャから削除(kill)すると500Errorがなくなり、正常に復帰しました。
ゾンビプロセスが発生する原因を推測しますと、その筋書きは、
になるのでないかと思います。
perlのゾンビプロセス(Zombie process)を監視して強制排除するバッチファイル
ゾンビプロセスの依存関係(親子関係)を無視して、タスクマネージャから削除(kill)するバッチファイルのshellスクリプトが AN HTTPD ゲストブック/コメント集(2004年11月16日03:39)と AN HTTPD 自動再起動プログラム anhttpd_restartで公開されていましたので、早速試してみました。 通常のPerlのプロセスの一括削除だけでしたら、大変実用的なバッチファイルだと考えました。
上記のWebページでは、起動プロセスの調査をするのに非常に有用なプロセス一覧表示コマンド(pslist.exe)とプロセス削除コマンド(pskill.exe)が紹介されています。 但し、Sysinternals Freeware - Utilities for Windows NT and Windows 2000 - PsToolsから、Pstools.zipをダウンロードして解凍し、私のサーバー機上でプロセス一覧表示コマンド(pslist.exe)を実行しますと、「Process performance object not found」というエラーが発生しました。
Windows 2000 Professionalで、pslist.exeを実行すると、 D:\bin>pslist.exe PsList 1.26 - Process Information Lister Copyright (C) 1999-2004 Mark Russinovich Sysinternals - www.sysinternals.com Process performance object not found on ログ中のユーザ名 Run Exctrlst from the Windows Resource Kit to repair the performance counters. と言うエラー表示が出る場合は、 ftp://ftp.microsoft.com/reskit/win2000/exctrlst.zip から、exctrlst.zipをダウンロードして解凍し、exctrlst.exeを実行して、 PerfProc perfproc.dllの行が反転する様にして、 レ Performance Counters Enabled という様にPerformance Counters Enabledにチェックを入れ「Refresh」ボタンを押すと、 正常にpslist.exeが実行できる様になります。 参考URL:パフォーマンスモニタの「Network Interface」を表示させる
perlのゾンビプロセス(Zombie process)を監視して強制排除するperlスクリプト
設置するのが難しいかもしれませんが、前項のバッチファイルをperlスクリプトに書き換えて、一部改造して見ました。 前項のWebページを参考(基底)にして、Windows用不良Perlプロセス削除スクリプト(2004.12.08 Rev.1.002)を作成しました。利点としては、
と考えています。起動方法は、
タスクスケジューラの例)
このPerlスクリプトは、WebサーバーのCGIとして実行されたPerlのプロセスと、他の常駐Perlプロセスとの識別に
「プロセス削除除外ファイル(PIDsafeList.txt)」を使用します。一般の用途では、空ファイルでも結構です。
プロセス削除除外ファイル(PIDsafeList.txt)には、削除したくないプロセス番号を1行に1個記入しておきます。
例)削除したくないperlの常駐プロセスがある場合は、
その常駐プロセスのperlスクリプトの先頭近くに
$PIDsafeFileName = "D:/bin/Pstools/PIDsafe.txt";
open(OUT,">>$PIDsafeFileName") || print LOG "$PIDsafeFileNameオープン失敗\n";
print OUT "$$\n"; # $$には、自己のプロセス番号が格納されています。
close(OUT);
と追記しておきます。
● 設置例
解凍したディレクトリに本スクリプトのperl_kill.plを設置して下さい。 D:\bin\Pstools (解凍ディレクトリ)---実行ユーザーでの実行権限と書き込み権限が必要 | \pslist.exe \pskill.exe \perl_kill.pl ※このスクリプトファイル自身。 \PIDsafeList.txt ※参照するプロセス削除除外ファイル。(空ファイルでも可) \PIDkilled.log ※出力するログファイル。
● 確認方法
コマンドプロンプト画面(DOS窓)を2つ開いておき、一方の画面で、「D:\bin\Pstools>perl perl_kill.pl」を実行します。 もう一方の画面で、「D:\>perl -e "sleep(3600);"」(1時間待ち状態のperlプロセス)を実行し、所定の時間で、このプロセスが削除されて、コマンド入力に戻ることを確認します。
● ログファイルの見方
WebサーバーのCGIとして実行されたPerlのプロセスで削除されたプロセスは、以下の書式で記録されています。
2004.11.21 21:44:06 ElapsedTime=0:01:06.004 Name=perl killed Pid=292(SafePID=XXXX XXXX ) Pri=8 Thd=1 Hnd=16 Priv=592 CPUtime=0:00:00.060
記録時間の2004.11.21 21:44:06から、ElapsedTimeの0:01:06.004を差し引いた時刻が削除されたプロセスの起動時刻になりますので、この時刻からWebサーバーのログファィルを見て、削除されたプロセスのCGIの種類を判別できると考えます。