自分の開発サーバではうまく動いていたCGIをレンタルサーバにアップロードしたらエラーになってしまう事はよくあります。このような場合にどのように原因を突き止めていくか、どんなレンタルサーバでも使える原始的な方法をご紹介します。

前提としては、自分の開発サーバでは一通りうまく動くプログラムが書けたと想定しています。うまく動くはずのプログラムを本番のレンタルサーバにアップロードしたら、画面が表示されなかったり、動作のどこかでエラーが起きるような場合に何から手を付けたらよいかの指針です。

エラー番号が 500 以上か 400 番台以下かを確認

エラーが起こったら、まずはブラウザに表示されているエラー情報を見てみます。レンタルサーバ会社によって画面のデザインは様々ですが、Webサーバは全世界共通でエラーの種類を表す番号を管理に使っていますので、まずは「500」や「403」などの番号が表示されていないか確認します。

番号はブラウザの画面に表示されている場合の他、タイトル部分のみに表示されている場合があります(図参照)。

画面上に表示されたエラー番号

画面上に表示されたエラー番号

タイトルに表示されたエラー番号

タイトルに表示されたエラー番号



ここで「403」などの 400番台以下の番号が表示されていたら、問題はプログラム内容ではなく、サーバの設定ミスです。パーミッションの設定や、そもそもページヘのアクセスやCGIの実行が許可されているか、サーバのマニュアルを調べて確認して下さい。「404」であれば、URLを間違えていないかどうかを確認します。

エラーログを見る

番号が表示されていない場合や表示されているのが500番以上のエラーの場合は、ブラウザから見ているだけでは原因が分かりません。この場合は、可能であれば「エラーログ」を見ます。「エラーログ」は、レンタルサーバであれば管理画面から見られることが多いです。もしエラーログに以下のような記載があれば、それぞれ設定で問題が解消できます。

よくあるエラーログ1
No such file or directory: exec of '(CGIのファイルパス)' failed
このエラーが出ている場合は、Perl のパスのミスの可能性が高いです。「Perl のパス」が開発環境とレンタルサーバで違っていないか確認して、違うのであれば変更してファイルをアップロードし直します。

よくあるエラーログ2
Can't locate MODULE.pm in @INC
このエラーの場合、「MODULE.pm」の所には、開発環境で使っている Perl モジュールが記載されているはずです。このエラーはサーバでこのモジュールが使えない事を意味します。管理者に頼んでインストールしてもらうなどの対応が必要です。もし追加のモジュールインストールができない場合は、プログラムの方をモジュールを使わない方式に書き換える必要があります。

CGIが動いているのか確認

上記以外にもエラーログには様々な情報が書き出されますが、エラーログを読んでも原因の見当がつかない場合、まずはCGIプログラムそのものが実行されているか確認します。ファイル冒頭の Perl パスのすぐ下に、下記のようなコードを追加してもう一度CGIにアクセスして下さい。
binmode STDOUT;
print "Content-type: text/plain
";
print "
";
print "I'm fine.
";

__END__
これは、「I'm fine. (元気ですよ。)」と表示するだけの簡単なプログラムで、「__END__」と書いた後は全てのコードが無視されます。「__」の部分は半角のアンダースコア2つです。

これでもブラウザのウィンドウに「I'm fine.」と表示されない場合は、CGIの実行自体がされていません。パーミッション等を含めてサーバの設定を見直す必要があります。