Q&A
この質問は、Pythonプログラムが、どう起動されたかを調べる方法 - https://teratail.com/questions/212553
の続きですか？ その時の修正が生きたまま、cgiであるpythonプログラムをデバッガーにアタッチした状態でリモートデバッグしている(デバッグ対象のプログラムは終わっていない)横から、ブラウザーで更にcgiを実行しようとしているということで合っていますか。
XSERVERに自力でPython3.7系をインストールして使用しています。
（linuxbrew／pipenvを利用）
サーバーの環境構築はド素人の為、色々なサイトの情報を参考にさせていただきながら、
手探りでなんとか構築しましたが、色々と分かっていないまま使っております。
現在、壁にぶつかっている問題は、表題の通りなのですが、
ごく簡単なPythonプログラム（後述）を、サーバー上に置き、
パーミッションを705に設定し、ブラウザからアクセスすると、動きます。
しかし、「Visual Studio Code」を起動し、リモート接続をしている間、
再度ブラウザからアクセスすると、「500 Internal Server Error」が出て、動かなくなります。
「Visual Studio Code」を終了させ、
再度ブラウザからアクセスすると、何事もなく動くようになります。
↓ごくごく簡単なPythonプログラム。test_hello.py（UTF-8 BOM無し／LF）
Python
1#!/home/（ユーザー名）/.linuxbrew/Cellar/pipenv/2018.11.26_2/libexec/bin/python3.7 2# -*- coding: utf-8 -*- 3print('Content-type: text/html\n\n') 4print("Hello World")
正確には、「Visual Studio Code」を起動しただけで問題が起こる訳ではなく、
「Visual Studio Code」のターミナル上でプログラムをデバッグしたり実行させたりすると、
動かなくなるようです。
- 「Visual Studio Code」起動、SSH接続でサーバーに接続
この時、ブラウザからアクセスした時の挙動：問題なく動く
この時、ターミナルで「python -V」を叩くと、「Python 2.7.5」が返って来る
- 「Visual Studio Code」のターミナル上で実行（ターミナルに表示される内容は後述）
この時、ブラウザからアクセスした時の挙動：「500 Internal Server Error」が出て、動かなくなる
この時、ターミナルで「python -V」を叩くと、「Python 3.7.4」が返って来る
- 「Visual Studio Code」を終了させる
この時、ブラウザからアクセスした時の挙動：問題なく動く
↓ターミナル上でプログラムを起動した時の、ターミナルの表示
terminal
1[（ユーザー名）@（サーバー番号） ]$ source /home/（ユーザー名）/.linuxbrew/Cellar/pipenv/2018.11.26_2/libexec/bin/activate 2(libexec) [（ユーザー名）@（サーバー番号） ]$ /home/（ユーザー名）/.linuxbrew/Cellar/pipenv/2018.11.26_2/libexec/bin/python3.7 /home/（ユーザー名）/（ユーザー名）.jp/public_html/XXXXX/test_hello.py 3Content-type: text/html 4 5 6Hello World 7(libexec) [（ユーザー名）@（サーバー番号） ]$
１行目の source ～ activate は、自分で打ち込んでいる訳ではなく、
「Visual Studio Code」の実行ボタン（Run Python File in Terminal）をクリックした時に
勝手に表示されて実行されている感じです。
「Visual Studio Code」のターミナル上で実行した時に、
サーバー内で何が起きているでしょうか？
実現したいことは、
「ブラウザからも「Visual Studio Code起動中」も、プログラムが実行できる状態にしたい」です。
なお、サーバーエラーログを確認すると、
「End of script output before headers」が記録されていました。
「print('Content-type: text/html\n\n')」は、ちゃんと入ってるのに…
また、パーミッション、文字コード、改行コードも問題ないはずです。
まとまりのない質問で申し訳ありません。
また、必要な情報も足りていないのではないかと思いますが、
どの情報が必要なのかも分かっておりません。
よろしくお願い申し上げます。
- Visual Studio Codeのバージョンは、1.42.0-insider
- サーバー：XSERVER X10プラン
- OS：Linux
- Apacheバージョン：2.4.6
- 自分でインストールしたPythonのバージョン：3.7.4
- XSERVERにデフォルトで用意されているPythonのバージョンとパス
Python2.7.x --- /usr/bin/python
Python3.4.x --- /usr/bin/python3.4
Python3.6.x --- /usr/bin/python3.6
dodox86さんから頂いた質問への回答１
環境としては先の質問と同じものですが、
VSCode側でリモートデバッグをしているまっ最中に、ブラウザから実行したいわけではありません。
（出来れば理想的ですが…）
VSCode側のリモートデバッグは完全に終わっているのに、
ブラウザから実行できないのです。
リモートデバッグは完全に終わっていると私は思っているのですが、
リモートデバッグをしたことで、多分、何らかの設定が変化してしまっていて、
VSCode起動直後の状態に戻っていない、というのが正しいかも知れません。
VSCodeでデバッグ実行直後、
source ～ activate が走っていることから、これを解除できれば良いのかもと思って
「deactivate」を試してみたのですが、
Pythonのバージョン表示はVSCode起動直後の状態に戻っていますが、
やはりブラウザからは、アクセス出来ませんでした。
↓VSCode上のターミナル上でデバッグ実行後、「deactivate」を叩いてみた
terminal
1[（ユーザー名）@（サーバー番号） ]$ source /home/（ユーザー名）/.linuxbrew/Cellar/pipenv/2018.11.26_2/libexec/bin/activate 2(libexec) [（ユーザー名）@（サーバー番号） ]$ /home/（ユーザー名）/.linuxbrew/Cellar/pipenv/2018.11.26_2/libexec/bin/python3.7 /home/（ユーザー名）/（ユーザー名）.jp/public_html/XXXXX/hello.py 3Content-type: text/html 4 5 6Hello World 7(libexec) [（ユーザー名）@（サーバー番号） ]$ deactivate 8[（ユーザー名）@（サーバー番号） ]$ python -V 9Python 2.7.5 10[（ユーザー名）@（サーバー番号） ]$
dodox86さんから頂いた質問への回答２
VSCode上でのターミナルで df コマンド(可能ならmountコマンド)を実行したときの結果はこちらになります。
コマンドの内容を全部載せたらteratailの本文の文字数制限に引っかかってしまったので、
VSCodeでプログラムを走らせる前と後を差分プログラムで比較した画像のみ掲載させていただきました。
dfコマンド
mountコマンド
VSCodeにした設定
VSCode起動後、サーバーにSSH接続した直後の画面で、「settings.json」を開いています。
プログラムを一度実行させた後の画面で、「launch.json」を開いています。
赤枠の部分が、「2.Python」に変わっていますが、これもよく分からないです。
dodox86さんから頂いた質問への回答３
launch.json のpathMappings:で
localRoot: "$`{workspaceFolder"}",
remoteRoot: "/home/..../.....jp/public_html/..../"
となっていて、デバッグ実行時にローカルPC上のワークスペースのディレクトリを
リモートの「/home/..../.....jp/public_html/..../」に再マップしているように思います。
VSCodeのエディタは、サーバーに置いてあるファイルを直接編集しているようです。
（ローカル側のファイルタイムスタンプはいつも古いままなので）
で、デバッグ実行時を走らせると、エディタのファイルパス表記が、
サーバー上のパスから、Windows上のパス表記に変わっている事に、今更ながら気がつきました。
また、localRootの方のフォルダ名を試しにリネームしてからデバッグ実行時をしてみたら、
（フォルダが存在しない状態にして実行してみたら）以下のエラーになりました。
ErrorMessage
1'test_hello.py' を開くことができません: ファイル 'c:\Users\xxxx\Desktop\xxxx\xxxx\test_hello.py' を読み取れません 2(Error: 存在しないファイル 'c:\Users\xxxx\Desktop\xxxx\xxxx\test_hello.py' を解決できません)。
ぬぬ？サーバー上ファイルをローカルに持ってきて
サーバー上でステップ実行しているように見せかけているの…？
ブラウザーでCGIのエラーが起きる状態で、
（VSCodeのターミナルではなく）別でsshでログインして
ユーザー環境を確認してみることはできますか。
「teraterm」でログインできます。
「ユーザー環境を確認」…すみません、何をどのように確認したら良いでしょうか？
また、Internal Server Error 500は、恐らくスクリプトの起動すらできていません。
CGIのエラーなどはhttpd(nginx)のエラーログ(/var/log/httpd/error.logとか)に保存されることが多いですが、
XSERVERだとhttpdのエラーを確認できるかどうか分かりません。可能であれば見てみてください。
XSERVERのサーバーパネルからエラーログがダウンロードできるのですが、これが「httpdのエラーログ」に相当するものでしょうか？
「Internal Server Error 500」が発生する時は、以下が記録されています。（質問本文にも記載しています）
ErrorLog
1[Fri Feb 07 13:11:48.013552 2020] [cgid:error] [pid 152796:tid 140141704247040] [client (うちのIPアドレス):55354] End of script output before headers: test_hello.py
dodox86さんから頂いた質問への回答４
cgiでの実行時とVSCodeのターミナルでの実行時にPATHや環境変数、ホームディレクトリ下のファイル状況が違っているのだろうと思い、
それらを確認するために、teratermなりでログインして、VSCodeでのターミナルログイン時と違うことを確認すればいいかと思いました、
面倒であればとりあえず結構です。
申し訳ありません、面倒だった訳ではなく、
単純にLinuxについて詳しくない為、何を確認して良いのかさっぱり分からず、あのような質問となりました。
お気に障りましたらお詫びいたします。
「teraterm」でSSHログインし、echo $PATH、printenvコマンドの結果を、
VSCodeでデバッグする前と後で比較してみましたが、こちらは変化がありませんでした。
「VSCode」でSSHログインし、「VSCode」のターミナル上で、
echo $PATH、printenvの内容を、VSCodeでデバッグする前と後で比較してみました。こちらは変化がありました。
また、「teraterm」のVSCodeでデバッグする前と、
「VSCode」 のターミナル上で、VSCodeでデバッグした後も比較してみました。
VIRTUAL_ENVが増えていたり、PWDが変わっています…
仮想環境がCGIの邪魔をしていますでしょうか？
回答１でも書かせていただいたのですが、
仮想環境がアクティベートされているのが原因ではないかと考え、
「deactivate」コマンドを試してみたのですが、状況は変わりませんでした。
dodox86さんから頂いた回答に対する返信
Shebangとしてシステムがあらかじめ用意しているインタープリターを指定
（例えば#!/usr/bin/python）した場合に問題がなければ、つまりは仮想環境のせいだと問題の切り分けができます。
test_hello.pyで、以下のShebangを試してみました。
Python
1#!/home/（ユーザー名）/.linuxbrew/Cellar/pipenv/2018.11.26_2/libexec/bin/python3.7 2#!/home/（ユーザー名）/.linuxbrew/Cellar/pipenv/2018.11.26_2/libexec/bin/python 3#!/usr/bin/python3.6（←XSERVER指定のもの）
いずれもVSCode上でも、CGIでも動きました。
但し、VSCodeでデバッグ後は、どれもCGIからは動きませんでした。
cgiスクリプト中でwhoamiコマンドを実行することで、cgiプログラム実行時のアカウントを確認することができます。
whoamiコマンドを実行してみました。
VSCode上で走らせても、CGIで走らせても、XSERVERのユーザー名が表示されました。
Shebangのhomeの次に書いてある（ユーザー名）と同じです。
赤枠の部分が、「2.Python」に変わっていますが、これもよく分からないです。
リモートデバッグでPythonインタープリターがデバッガーにアタッチしたままだから、だと思います。
ご指摘の通りです。
ここにヒントがありました。
（参考）Pythonで仮想環境virtualenvを作成し、Visual Studio Codeで自動適用する開発環境を構築する
https://qiita.com/psychoroid/items/6646d45d6a019f5cf16f
VSCodeが自動的に仮想環境をactivateしているようです。
この時、シェルもbashからPythonシェルに自動的に切り替わるようで、
その為、赤枠の部分が、「2.Python」という表示に変わっているようです。
仮想環境のactivate.batが実行されることで仮想環境に入り、
仮想環境に入ったことを示す(env)がターミナルの頭に付きます。
ということなので、activateが走る前後で、ターミナルの表示が変わるのは、
そういう事なのかと理解しました。
activateが走る前 ----- [（ユーザー名）@（サーバー番号） ]
activateが走った後 --- (libexec) [（ユーザー名）@（サーバー番号） ]
以前、「deactivate」を叩いてもダメだったと書きましたが、
試しに、「deactivate libexec」と叩いてみたら、上記の表示が、「activateが走る前」の状態に戻りました。
更に、exitを叩くと、Pythonシェルから抜け、
赤枠の部分が、「1.bash」に戻りました。
もう一度、exitと叩くと、ターミナルウインドウ自体が終了し、
CGIから、プログラムが走るようになりました。
deactivateをしたとしてもVisual Studio Codeを終了させるまでは
仮想環境のファイルやディレクトリが有効なままかもしれません。
これが当りだと思われます。
ターミナルウインドウの終了＝仮想環境の適用終了になっているようです。
VSCodeを終了させなくても、仮想環境の適用を解くことは出来るようになりましたが、
これではVSCodeを終了させているのと、（手間的に）あまり違いがないので、もう少し粘ってみたいと思います。
（ちょっと長くなりすぎたので、一度こちらはクローズするかも知れません）
大変申し訳ないですが時間切れの為、今回、お答えできなかった部分についてはまたの機会とさせていただきます。
尚、Visual Studio Codeに導入したエクステンションは、
沢山入れてしまっているので、どれがどう影響しているのか不明なのですが、
リモートデバッグ絡みだと以下の２つだと思われます。
- Remote - SSH（Misrosoft）
- Remote Development（Microsoft）
dodox86さん、お問合せ頂き、ありがとうございます。
回答を追記しましたので、よろしくお願い申し上げます。
XSERVERと言うことは他ユーザーも同居している環境でしょうか。nginxなどのサーバー環境は他ユーザーと共有ですよね。
リモートデバッグをできるようにする上で恐らく様々な設定をされていると思いますが、Visual Studio CodeでSSH FSなどを用いてターミナルでログインしたときに参照先のマウントディレクトリを変えているものと思われます。そうだとすると、VSCodeでターミナル使っているときのみユーザー環境が置き換わり、ブラウザからのnginxを経由したCGI実行に影響する気がします。
VSCode上でのターミナルで df コマンド(可能ならmountコマンド)を実行したときの結果は提示できますか。ホームディレクトリの一部が置き換わっているかもしれません。
dodox86さん、ありがとうございます。ご指摘の通り、他のユーザーも同居している環境です。
dfコマンドやmountコマンドの結果を追記しましたので、よろしくお願い申し上げます。
情報のご提供ありがとうございます。他ユーザーとの共有サーバーだけあってユーザーごとの仮想化がされていると見え、簡単ではなさそうです。解決へは至れませんが、意見として追って回答を投稿させてもらいます。
確認ですが、VSCodeのワークスペース、つまりlaunch.json で指定している"localroot:"の ${workspaceFolder}ですが、ローカルPC上に存在するワークスペースですね？
はい、その通りです。${workspaceFolder}は、VSCodeの変数置換構文です。
（参考）https://qiita.com/ShortArrow/items/dc0c8cacd696154510f1
ちょっと気になって確認もしました。${workspaceFolder}を使わず、Windowsの絶対パスで書き換えてみましたが、同じように動作しています。
launch.json のpathMappings:で
localRoot: "$`{workspaceFolder"}",
remoteRoot: "/home/..../.....jp/public_html/..../"
となっていて、デバッグ実行時にローカルPC上のワークスペースのディレクトリをリモートの「/home/..../.....jp/public_html/..../」に再マップしているように思います。その環境が生きたままですと、ブラウザーからCGIを起動するとオリジナルの環境が変わっていることになって、エラーが起きているのでは。ブラウザーでCGIのエラーが起きる状態で、（VSCodeのターミナルではなく）別でsshでログインしてユーザー環境を確認してみることはできますか。
また、Internal Server Error 500は、恐らくスクリプトの起動すらできていません。CGIのエラーなどはhttpd(nginx)のエラーログ(/var/log/httpd/error.logとか)に保存されることが多いですが、XSERVERだとhttpdのエラーを確認できるかどうか分かりません。可能であれば見てみてください。
dodox86さん、何度もありがとうございます。回答３を本文に追加しましたので、よろしくお願いします。
失礼しました。httpdはnginxだと思い込んでましたが、apacheでしたね。（質問中にちゃんとApache 2.4.6 である旨、記載済み）
> 「teraterm」でログインできます。 「ユーザー環境を確認」…すみません、何をどのように確認したら良いでしょうか？
cgiでの実行時とVSCodeのターミナルでの実行時にPATHや環境変数、ホームディレクトリ下のファイル状況が違っているのだろうと思い、それらを確認するために、teratermなりでログインして、VSCodeでのターミナルログイン時と違うことを確認すればいいかと思いました、面倒であればとりあえず結構です。
dodox86さん、回答４を追加しましたので、よろしくお願いします。
度々申し訳ありません。
はい、httpdはapacheです。
XSERVERは、契約した時期によってnginx または apacheになります。
> お気に障りましたらお詫びいたします。
いえ、それほどの意味で「面倒だったら」と書いたわけではなく、未知な環境な部分があったので、手間がかかる割に得るものが少ないかもしれないと思い、書いたまでです。気にしないでください。
> 仮想環境がCGIの邪魔をしていますでしょうか？
それを疑っています。CGIはapacheで設定されたユーザーアカウントで動くので(XSERVERならユーザー個別でしょう）、各ユーザーが環境を変えたら、それぞれで影響を受けるはずです。エラーメッセージ中に"cgid"の文字がありますが、apacheのmod_cgidモジュールを介し、cgidデーモンが動き、cgi稼働時には各ユーザーの1プロセスと動作しているはずです。ですので、仮想環境への変更が影響しているのでは、と思っています。
回答2件
0
ベストアンサー
解決への直接的な回答ではありません：
Visual Studio Codeを使って試してみましたが、質問者であるchibi_kumaさんと同じようには再現できませんでした。リモートデバッグ環境の差異が大きいせいだと思います。（pyenvをお使いですが、それに加えてSSHのターミナル接続環境、XSERVERでの他ユーザー同居の環境など、分からない点が未だ多い）
ですが、質問者さん自身で既にお疑いのようにVisual Studio Codeで接続し、リモートデバッグを始めた後、Visual Studio Codeの接続を終了するまではサーバー上のオリジナルの実行環境が変わったままになる（≒仮想環境が既存の環境でのpythonスクリプトの実行を阻害している）ことが原因である、と言うことは言えていそうです。
当該cgiプログラムの1行目のShebangですが、
Python
1#!/home/（ユーザー名）/.linuxbrew/Cellar/pipenv/2018.11.26_2/libexec/bin/python3.7
Internal Server Error 500 / "End of script output before headers" のエラーは、このインタープリター指定が恐らく無効になっている（実行できない）ためだと思われます。仮想環境でのpython3.7でスクリプト実行ができないため、続くprint('Content-type: text/html\n\n')...が実行されず、"End of script output before headers" のエラーが発生します。
Shebangとしてシステムがあらかじめ用意しているインタープリターを指定（例えば#!/usr/bin/python）した場合に問題がなければ、つまりは仮想環境のせいだと問題の切り分けができます。
apache2のcgiは、apache2の設定で指定されたユーザーアカウント("www-data"など)のプロセスとして起動しますが、このときのアカウントや動作環境はターミナルでログインしたときのものとは必ずしも同じではありません。（と言うか、違うのが普通）Visual Studio Codeでリモートデバッグを始めたとき、virtualenv（？）のactivateコマンドで仮想環境のアクティベートをさせていますが、deactivateをしたとしてもVisual Studio Codeを終了させるまでは仮想環境のファイルやディレクトリが有効なままかもしれません。Linuxではあるファイルをプロセスが使用中でも、別のプロセスが削除できます。使用中のプロセスは、ファイルを閉じるまでそのまま使用できます。
あといくつか、思いつくことを列挙してみます。
-
activateやdeactivateコマンドは恐らくシェルスクリプトだと思いますが、その内容を読むことで解決へのヒントが得られるかもしれません。 -
cgi実行時のアカウントは
www-dataなどのapache2の設定によるものだと書きましたが、XSERVERは他ユーザーと同居しているサーバーなので、ユーザーごとの設定はユーザーそのものになっているかもしれません。その場合は例えばcgiスクリプト中でwhoamiコマンドを実行することで、cgiプログラム実行時のアカウントを確認することができます。 -
「
dfコマンドやmountコマンドでの実行結果を提示してください」と書いたのは、Visual Studio Codeの実行時にディレクトリのマウントをしているのではないかと疑ったからですが、結果からしてそうではなさそうだし、XSERVERの性質上からしてもそんなことはできなさそうであるので、原因の候補から外してよいです。 -
回答2で、
プログラムを一度実行させた後の画面で、「launch.json」を開いています。
赤枠の部分が、「2.Python」に変わっていますが、これもよく分からないです。
とありますが、リモートデバッグでPythonインタープリターがデバッガーにアタッチしたままだから、だと思います。
launch.jsonで、localRootで指定するローカルPC上のワークスペースをremoteRootで示すディレクトリにマウントしていますが、何かおかしい気もします。問題が起きるのはそのせいもあるのではないかと思うのですが、こちらでは再現できないので、疑念の提起に留めます。
上記、あくまで推測の域を超えない回答ですので、異議を含めて、他回答者様からの意見を私も望むものです。
投稿2020/02/10 01:37
総合スコア9267
dodox86さん、こんなに沢山ヒントを頂き、誠にありがとうございます。
少し精査にお時間を頂戴したいと思います。
誠に申し訳ありませんが、よろしくお願い申し上げます。
回答にも書きましたがあくまで推測であり、私自身が解決を急ぐものではありませんのでごゆっくりどうぞ。Visual Studio Codeに導入したエクステンションも質問に提示されると良いかもしれません。SSH FSとか、Remote Development とか色々あるようですし。
長らくお待たせしてしまい、申し訳ありませんでした。
「dodox86さんから頂いた回答に対する返信」を追記しました。
いままでボヤっとしていたところが分かってきましたし、
仮想環境が影響している事は確実だと思うのですが…ちょっと惜しい。
VSCodeで仮想環境がactiveになっていても、CGIの起動に影響しなくなる設定が理想的なのですが…
その後の確認作業に関するご報告、ありがとうございます。拝見しました。
> 大変申し訳ないですが時間切れの為、今回、お答えできなかった部分についてはまたの機会とさせていただきます。
私が提起した懸念点に限っては、現時点で充分答えられていると思うので、必ずしも細かい部分について全部お答えいただく必要はありません。質問～回答の体裁が整えばまずは良いのではないでしょうか。本質問で完全に解決に至らなかったら自己回答でいったん閉じてもいいと思いますし、判断はお任せします。
0
残念ながら、解決には至りませんでした。
ずっと調べておりましたが、いたずらに時間ばかりが過ぎてしまい、
現在の自分ではちょっと解決に至りそうにはありませんでしたので、
ここでいったんクローズとさせていただく事にしました。
dodox86さんには、ずっと丁寧にお付き合いをいただき、感謝申し上げます。
長らく放置状態になってしまった事をお詫び申し上げます。
また機会がありましたら、ご指導いただきますよう、お願いを申し上げます。
ありがとうございました。
投稿2020/04/03 05:49
総合スコア85
あなたの回答
tips
プレビュー
