Webサーバー(Python)でChromeに実行権を掴まれているような現象について

Question

お世話になります。
手がかりになる発想や視点だけでも結構ですので皆様の力をお貸しください。

前提

CentOS7、Apache、mod_wsgi、Django+PythonでWebサーバーを構築しました。
簡単なブログサイトで本番環境にデプロイ済です。
下記手順の①、②で他ブラウザからのアクセスができない状態となるため、これを何とかしたいです。

発生している問題

下記、手順の②でページAのレスポンスが返ってこない理由が分からず、煮詰まっております。
① GoogleChromeでページAにアクセスする。（ページAが表示される）
② GoogleChrome以外のブラウザ（IEやFireFoxなど）でページAにアクセスすると、レスポンスが返ってこない。
③ ①にて自サイトを含む任意のサイトに何かしらリクエストすると、②のページAのレスポンスが返ってきて表示される。

また、①をIEで実施、②をChromeで実施すると②でレスポンスが返ってきます。

試したこと

PythonなのでGIL（シングルプロセス）が関係しているのでしょうか。
試しにwsgi.pyに対して、multiprocessingで確認しようとしましたが良く分からず挫折しました。。。
ブラウザによって挙動が違うのでマルチプロセスにしたところで、解決できないかもしれません。
ApacheやDjangoのログを見ても特にエラー等は出ておらず、目の付け所すらわからなくなっており、もう一週間ほどハマっております。

何かしら手がかりになりそうなことや些細なことでも結構ですのでアドバイスよろしくお願い致します。

追加情報

◆ ①の時点でファビコン(Chromeタブ左上)は回転してなく、チカっとなってバシッとファビコンが表示されています。
◆ ページAと表記していますが、特定のページのみを指しているのではく、
「ページA = 自サイト全てのページ」という意味です。
◆mod_wsgiの設定
デーモンモードにしております。以下、django.conf内です。

Alias /static /var/www/vops/ops/static
<Directory /var/www/vops/ops/static>
    Require all granted
</Directory>

<Directory /var/www/vops/ops/ops>
    <Files wsgi.py>
        Require all granted
    </Files>
</Directory>

WSGIDaemonProcess vops user=apache group=apache processes=2 threads=25 maximum-requests=10000 python-path=/var/www/vops:/var/www/vops/lib/python3.6/site-packages
WSGIProcessGroup vops
WSGIScriptAlias /ops /var/www/vops/ops/ops/wsgi.py

◆Chromeの設定「Enable new preconnect predictor」をDisabledにすると下記挙動に変化する。
(Chromeの履歴(キャッシュ)をクリアした時と同じ挙動となる。)
① ChromeからページAをリクエスト⇒表示される。
② Chrome以外でページAをリクエスト⇒表示される。
③ ChromeからページAをリクエスト⇒表示される。
④ Chrome以外でページAをリクエスト⇒表示されない。(レスポンスが返ってこない)
⑤ ③にて自サイトを含む任意のサイトに何かしらリクエストすると④のレスポンスが返ってくる。

Comments

[umyu]

1, 手順①の時に、chromeのタブ左上のアイコンのマークは回り続けていますか？
2, mod_wsgiの組み込みモード、デーモンモードどちらで動作させていますか？質問文にmod_wsgiの設定を追記していただくことは可能でしょうか。

[s-hama]

追記依頼ありがとうございます。質問へ追加情報を追記しました。ご確認よろしくお願いいたします。

Answer 1

非常に情けない結果となりましたが、下記の通り自己解決しました。
※設定等の間違いによるものではありませんでした。

Apache(80ポート自社の簡易HP用)、Django(8080ポートで開発モード)で起動してる状態でしたので、Apache(80ポート)はデーモンモードでマルチプロセスで動き、Django(8080ポート)は開発モードで動いている状態でした。
（当たり前ですね。そもそも本番環境の動かし方がおかしい。。。）

SSLのグローバル環境で、Djangoをrunsslserverで起動し、8080ポートも開けて、DEBUG=FALSEとした状態で動いているDjangoに対して、本件が発生しており、"DEBUG=FALSE"だから本番で、Apache起動とDjango起動（manage.py runsslserver）はセットだと思い込んでいました。。。

サーバーログを流し読みしてきた、ツケはこんな形で回ってくるんですね。。。
スペシャリストに調査依頼する直前に気づいたことがせめてもの救いです。

開発モードでもなぜ、Choromeだけこのような現象が起きていたか不明ですが、開発モードなので、そこは重要ではないですね。
現在は、ポートを分けず、サブディレクトリを掘るように設定を変えております。

Comments

[umyu]

@UNISIA-SEさんへ
解決して、よかったですー。

Answer 2

質問文に追記ありがとうございました。

些細なこと

とのことなので、そこまで詳しい訳ではないのですが。

WSGIDaemonProcess vops python-path=/var/www/vops:/var/www/vops/lib/python3.6/site-packages

processesを定義していないので、1プロセスしか立ち上がらないのでは。

WSGIDaemonProcess#processes=num

processes=num

Defines the number of daemon processes that should be started in this process group. If not defined then only one process will be run in this process group.

◆参考情報
why-are-you-using-embedded-mode-of.html

---

動作の症状を見る限りかなり憶測が入りますがchromeのpreconnect機能がものすごく怪しいのですが。

chrome://flags/を開いてEnable new preconnect predictorをdisableに変更後
chromeを再起動しても改善されませんか？
あとはAjaxを使っているならAjaxのCacheの可能性もあるかもです。

---

python-path=/usr/local/sites/www.site.com/lib/python2.5/site-packages

1, 質問のタグだとPython3の環境だったのでは？
Python2.5のsite-packagesになっています。

2, 公式のマニュアルを見て、最初から設定しなおしてみるとかでしょうか
参考:Django を Apache と mod_wsgi とともに使うには？

3, 本当にデーモンモードで動作しているどうかのかの確認は既に行いましたか？
回答の参考情報として既に記載済みですがwhy-are-you-using-embedded-mode-of.htmlを参考に確認してみてくださいな。

4, 自力で解決するめどが付かないのなら、詳しい人にお金を払って設定してもらうのも一つの手かと。

Comments

[s-hama]

ご回答ありがとうございます！！

「Processes定義」を試してみましたが結果は同じでした。
※設定内容は追加情報を更新しております。

また、「Enable new preconnect predictor」をDisabledにしたところ、少し、挙動に変化がありました。
(Chromeの履歴(キャッシュ)をクリアした時と同じ挙動となりました)

↑詳細は、追加情報に記載しますので、ご確認頂けると幸いです。

[s-hama]

ご丁寧な回答ありがとうございます！

まず、ご指摘の通り、Python2.5ではなく3.6となります。
昨日Processes定義の設定を追加した際の他者の設定をコピペし、編集を忘れあろうことかそのまま動かしていました。。。（挙動が変わらず動いていたのが不思議ですが）
大変失礼しました。(追加情報は元のPython3.6に修正しました)

アドバイス頂きました
「2.」のマニュアルの見直しと「3.」の参考情報の確認を腰を据えてじっくり確認したいと思います。
結果が出せず焦りすぎていました。。。（汗）
自力解決できない場合、スペシャリストに頼んでみようと思います。

現時点で最良の回答だと思いましたので、ベストアンサーにさせていただきます。
今後、何か原因が分かりましたら追記するように致します、いろいろとアドバイスありがとうございました！

[umyu]

@UNISIA-SEさんへ
ベストアンサー(BA)を付けていただけるのは嬉しいのですが。
問題が解決していないならば、この質問と同じ問題を抱えた人が後から見た時に困ると思うので、
ベストアンサーは外して頂ければ幸いです。

[s-hama]

確かにそうですね^^;
ベストアンサーを外しました。

解決次第追記しますね。
これから本腰入れて調査します。

[s-hama]

現時点でまだ未解決ですが、
アドバイス頂いた1, 2, 3(これはデーモンモードになっていました)を行い、マニュアルも読み倒し、ほかの設定も見直しましたが原因が特定できませんでした。
ログを見る限り、Apache(mod_wsgi)はデーモンモードの設定（WSGIDaemonProcess）で動き、Djangoは、1プロセス、1スレッドで動いています。
そもそも、Apacheを停止してもDjangoだけで動いており本現象が発生しており、それぞれ独立して動いているような挙動です。

Answer 3

すでに試していらしゃるとは思いますが、
同端末の他ブラウザでの試行でなく、他端末からの施行ではどうでしょうか？

①と②を実施する端末を分けるという意味です。

Comments

[s-hama]

ご回答ありがとうございます!

別端末も以下の手順で確認しています。

① Chrome(自宅でPCから)でページAにアクセスして表示される。
② Chrome(自宅でスマホから)でページAにアクセスして表示されない。
③ ①で何かしらリクエストすると②が表示される。
(①と②の端末を逆にしても結果は同じでした)

①のアクセス後、レスポンスは返り、表示されているが、サーバーサイドでは何かしらのエラーが発生していて(推測)、プロセスを掴んだままになっているような動きに見えます。
(②ではプロセスの解放待ちになっているような動きっぽい)

そこでログを仕込んで確認したいのですが、
Pythonのサーバー処理でget_queryset(リクエストを返すpythonのコアメソッドをオーバーライドしたもの!?)の実態がどこの処理にあたるのか(どこのコアソースが実行されているのか)分かりません。。。

もし、この辺りもご存じでしたらご教授よろしくお願いいたします。