Назад | Перейти на главную страницу

Apache VisualSVN Server не запускается с TCP-портом

По какой-то причине после обновления клиента SSH Tectia с версии 6.0 до 6.1 на моей рабочей станции Windows XP VisualSVN 2.0.7 не может запустить службу Apache после перезагрузки.

Event Type: Information
Event Source:   VisualSVN Server 2.0
Event Category: Apache 
Event ID:   1000
Date:       9/30/2009
Time:       3:37:48 PM
User:       N/A
Computer:   4-J25A
Description:
Disabled use of AcceptEx() WinSock2 API


Event Type: Error
Event Source:   VisualSVN Server 2.0
Event Category: Apache 
Event ID:   1002
Date:       9/30/2009
Time:       3:37:48 PM
User:       N/A
Computer:   4-J25A
Description:
alloc_listener: failed to get a socket for (null)
(OS 10106) The requested service provider could not be loaded or initialized.  


Event Type: Error
Event Source:   VisualSVN Server 2.0
Event Category: Apache 
Event ID:   1000
Date:       9/30/2009
Time:       3:37:48 PM
User:       N/A
Computer:   4-J25A
Description:
Syntax error on line 25 of C:/Program Files/VisualSVN Server/conf/httpd.conf:


Event Type: Error
Event Source:   VisualSVN Server 2.0
Event Category: Apache 
Event ID:   1000
Date:       9/30/2009
Time:       3:37:48 PM
User:       N/A
Computer:   4-J25A
Description:
Listen setup failed

Если я напрямую запускаю процесс apache VisualSVNServer.exe, он может работать и принимать запросы, но консоль управления VisualSVN по-прежнему считает, что служба остановлена. Я недостаточно знаком с версией Apache для Windows, чтобы понять, что мешает ей защитить заявленный порт 8443 (или может быть любой другой номер порта в этом случае)?

Я исправил свою проблему с установкой VisualSVN Server. Я видел много ошибок, включая указанную выше. Я отлично работал с VisualSVN Server долгое время, но после недавнего обновления Windows и перезагрузки мой сервер не вернулся. В конечном итоге сотрудники службы поддержки вернули его в онлайн, но сервер SVN не работал, и я не мог его запустить, поэтому решил, что просто обновлю его и позволю установке исправить любые проблемы. Я подумал, что, возможно, был поврежден жесткий диск, который можно было исправить таким образом.

В конце концов я узнал, что второй IP-адрес, который у меня был на сервере, больше не был настроен. А ранее у меня был сервер SVN / Apache, настроенный на использование определенного IP-адреса, которого больше не было.

[HKEY_LOCAL_MACHINE\SOFTWARE\VisualSVN\VisualSVN Server]

Этот ключ реестра - это именно тот, который указывал отсутствующий IP-адрес и, вероятно, вызвал все мои проблемы. После того, как я добавил IP-адрес в качестве дополнительного IP-адреса, я смог успешно запустить установку и получить доступ к серверу с моего клиента SVN.

В этом разделе реестра есть значения для ServerBinding и ServerName, которые необходимо использовать для запуска Apache. К сожалению, процесс установки VisualSVN Server не позволяет мне просматривать или изменять IP-адрес или имя сервера. Это избавило бы меня от многих проблем и раскрыло бы настоящую причину моих проблем.

Что касается управления IIS и Apache на одном сервере с двумя IP-адресами, вам нужно указать IIS, чтобы он не использовал второй IP-адрес. Следующая команда выполняет эту работу.

netsh http delete iplisten ipaddress=333.333.333.333

Очевидно, это поддельный IP-адрес. Замените его вторым IP-адресом. Следующая команда покажет вам, какой IP-адрес разрешено использовать IIS.

netsh http show iplisten

Для успешного применения этих изменений может потребоваться перезапустить IIS или перезагрузить компьютер. Windows выделяет управление перечисленными IP-адресами на ранней стадии цикла загрузки, поэтому вы хотите убедиться, что они не используются, чтобы Apache мог их использовать.

И если у вас возникнут проблемы, еще раз проверьте, что второй IP-адрес настроен для сервера. Все мои проблемы были просто из-за отсутствия конфигурации IP.

Я попытался восстановить и переустановить VIsualSVN Server, но безрезультатно. И только после того, как я удалил SSH Tectia Client, Apache VisualSVN Server снова запустился правильно. Установка клиента SSH Tectia после этого, похоже, больше не вызывает проблем. Надеюсь, так и будет.