仕事で使う資料のバージョン管理のため、WindowsサーバーにSubVersionサーバーをインストールしてもらって、クライアントはTortoiseSVNで使ってます。
もう3年くらい、一度のエラーもなく安定して使ってたのですが、ある日突然こんなエラーがでました。
Unable to connect to a repository at URL 'https://svn.XXXXXXXX/'
The server at 'https://svn.XXXXXXXX' does not support the HTTP/DAV protocol
調べたところ、「does not support the HTTP/DAV protocol」の意味するところは「URLが無効だ」ということのようです。
おそらく、Webサーバー（今回はApatch）が動いていないのでしょう。
停止した原因はわかりませんが、原因を取り除いて、Webサーバーのサービス（httpd）を開始すれば、復旧するだろうなということは確認できました。
それほど難しい作業ではないので、自分がやっとくよ・・ということになりました。
SubVersionサーバーは、この手順を参考に構築したとのことです。
確認すると、Subversionというサービス名で「"C:\Apache24\bin\httpd.exe" -k runservice」を登録してあるのですが、こいつが停止してました。
Confファイルをチェックしても特にエラーはありません。
でも、サービスの開始をしてみるとエラーになります。
メッセージは、「・・アクセスできません」とのこと。
そこで、ファイアウォールの設定とか、一通りチェックしましたが、正常稼働時の状態の記録資料と全く同じです。
そこで、使用中のポートを調べてみました。
netstat –nao | find “:80”
netstatのオプションは
で、findでポート80を抜き出してます。
すると・・。
いました・・こいつが原因です。
上記で、LISTENINGしているPIDを、タスクマネージャで確認しておいかけると、IISが動いてました。
IISのサービス名は「W3SVC」で、表示名は「World Wide Web 発行サービス」です。
確認すると、確かに「実行中」です。
しかも、スタートアップの種類が「自動」になってます。
これでは、Windowsアップデートで再起動した場合に、IISのサービスが先にあがってしまって、Subversionサービスの邪魔をする・・なんて、普通におこりえます。
たぶん。
今回、それが本当に発生したのでしょう。
原因がわかれば対処は簡単です。
W3SVCサービスを停止して、スタートアップを「無効」にします。
その後、Subversionサービスを開始したら、すんなり復旧しました。
不思議なのは。
W3SVCサービスのスタートアップの種類が何故「自動」だったのか？です。
実は、IISは初期設定時に無効にしてあると聞いてましたし、実際、作業記録にも証拠が残ってました。
だいいち、自動のままだったら3年間の間に、同じことが発生してたはずです。
かといって。
誰かが、わざわざ変更するとも思えないし、Windowsアップデートが無効のサービスを自動に変えてしまうなんて、聞いたことがないです。
ということで、根本原因はわからないままなのですが、IISが起動してもポートがバッティングしないように、無効にするだけじゃなくて、IISのポートを変更しておくとかしとかないとダメだね・・初期設定時の手順漏れだね・・みたいな話になったようです。
同じ原因で再発はしないでしょうけど。
なんか、狐に化かされたみたいな・・妙な後味ではありました。
ではでは。