NetBeansでリモートデバッグできなくなった

最近はCakePHPで開発をしていますが、フレームワークをIDEなしで開発するのは（少なくとも自分には）非現実的だと悟ったので、デバッグはもっぱら Xdebug+NetBeansによるCakePHPのデバッグ の手順に従ってNetBeansを使っています。

今日 NetBeans を使ったら、ふとしたことからリモートデバッグが動かなくなったので、原因を調査した時のメモです。

最初の症状としては、デバッグ開始後サーバからの応答待ちのまま先に進まない（ソースの開始行まで到達しない）が、IDE単体としては問題なく動いている、という感じです。

サーバ側で Xdebug の設定は以下のようにしています。Xdebug はポート 9000 を使っています。

$ grep ^xdebug /etc/php.ini
xdebug.remote_connect_back = on
xdebug.remote_port    = 9000
xdebug.remote_handler = dbgp
xdebug.remote_enable = On
xdebug.remote_log = /tmp/xdebug_remote.log
xdebug.idekey = netbeans-xdebug

端末(Windows)側でネットワークの状態を確認します。ちなみにすっかり忘れてましたが、以前 Windows に gow を入れていたようで grep 等が使えるようになっていました。

gow - Unix command line utilities installer for Windows.

W:\>which grep
C:\Program Files (x86)\Gow\bin\grep.EXE
W:\>netstat -an | grep -w 9000
  TCP    10.28.1.53:9000           10.30.8.31:54321           CLOSE_WAIT

10.28.1.53 が開発機(Windows7 Pro)、10.30.8.31 がサーバ(CentOS7)です。

デバッグを中止してからしばらく待っても CLOSE-WAIT のまま。これは端末側のネットワークの内部状態がおかしくなっていると判断し、パソコンをリブートしたらこの状態は解消されました。

ただ、ブレークポイントで止まらないのは相変わらず。

今度はサーバ側で tcpdump を仕掛けてからデバッグを開始し、パケットを監視してみました。

root@germany:~# tcpdump -n -nn port 9000
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
11:07:54.998420 IP 10.30.8.11.36562 > 10.28.1.53.9000: Flags [S], seq 2531464156, win 14600, options [mss 1460,sackOK,TS val 1533355514 ecr 0,nop,wscale 7], length 0
11:07:55.238767 IP 10.30.8.11.36563 > 10.28.1.53.9000: Flags [S], seq 4273096071, win 14600, options [mss 1460,sackOK,TS val 1533355754 ecr 0,nop,wscale 7], length 0

サーバから端末に対して ポート 9000 への接続を張りに来ていますが、相変わらず端末がそれを無視しています。

W:\>netstat -an | grep -w 9000
  TCP    0.0.0.0:9000           0.0.0.0:0              LISTENING
  TCP    [::]:9000              [::]:0                 LISTENING

端末側ではポートの待ち受けはしているようですが、まったくパケットを受けていない状態。 これは Windows 側のファイアーウォールが疑われるので、設定を見てみます。 まず、動いているプロセスのパスを調べます。

netbeans64.exe で右クリックしてプロパティを開きます。

フルパスは C:\Program Files\NetBeans 8.0\bin\netbeans64.exe ということがわかります。次は　コントロール パネル＞システムとセキュリティ＞Windows ファイアウォール＞詳細設定＞受信の規則　を開きます。

実はここを開いた直後は、NetBeans の過去のバージョンに対するルールがたくさんゴミとして残っていました。気持ちが悪いので、旧バージョンの分はすべて削除しました。プログラムのアンインストールをしても、ルールは自動では消えてくれないんでしょうかね？

これによると、現在の状態は「ドメイン」は許可、「パブリック」はブロックになっています。 これは Windows(NT/AD) ドメインではなくネットワークプロファイルの用語のようです。 画面右下のアイコンにマウスを乗せると、現在の状態が表示されます。

この表示は「識別されていないネットワーク」につながってると言いたいのか、 それとも「アクセスできるネットワークがない」と言いたいのか…。

というか、そもそもルールが二重に登録されている時点でおかしい。

ということで、二重になっている部分を「ドメイン」と「パブリック」がそれぞれ１行だけになるようにしました。

ここまでシンプルにして、再度挑戦します。

どう見ても「パブリック」がブロックになっていることが原因のように思えます。 と思いきや、「パブリック」を許可しても、状況は変わりませんでした。

ファイアーウォールルールのエントリに不整合が出ているようなので、 いったん「NetBeans」のルールをすべて削除した後、 再度デバッグを開始したら、以下のダイアログが表示されました。

これで再度「アクセスを許可」してやったらうまくいくようになりました。めでたしめでたし。