4

В течение двух дней я вносил много изменений в мой конфиг Apache. Временами изменения, похоже, не регистрировались, и всегда был случай, когда я как-то испортил синтаксис файла конфигурации, что-то, что всегда показывает apachectl -t . Системный журнал также будет отображать сообщения об ошибках, связанных с восстановлением httpd.

На следующий день мне нужно было внести некоторые дополнительные изменения, и я заметил, что Apache их не подобрал. Я хотел увидеть ошибки в apache error_log, но там было нечего видеть. Удаление их и перезапуск apache ничего не сделали. Файлы даже не были воссозданы!

Поэтому, конечно, я снова проверил синтаксис, и apachectl -t выплюнул Syntax OK . Кажется, там все в порядке. Затем я проверяю свой системный журнал, и он полон ошибок, касающихся httpd:

Mar 13 11:03:41 skinny com.apple.launchd[1] (org.apache.httpd[22707]): Exited with code: 1
Mar 13 11:03:41 skinny com.apple.launchd[1] (org.apache.httpd): Throttling respawn: Will start in 10 seconds

Остановка, запуск, перезапуск с apachectl абсолютно ничего не сделал. Но мне действительно удалось получить доступ к localhost. Так что же происходит?

1 ответ1

4

Как только я понял, что на самом деле могу получить доступ к localhost через порт 80, даже если я произвел apachectl stop , путь к освещению был свободен. Мне нужно было выяснить, что на самом деле занимало порт 80, и убить его.

Сначала я проверил, что на нем держится

netstat -ta |grep LISTEN
tcp4       0      0  *.65374                *.*                    LISTEN     
tcp4       0      0  *.65373                *.*                    LISTEN     
tcp4       0      0  *.spytechphone         *.*                    LISTEN     
tcp4       0      0  *.blp1                 *.*                    LISTEN     
tcp4       0      0  *.8193                 *.*                    LISTEN     
tcp46      0      0  *.http                 *.*                    LISTEN     
tcp4       0      0  localhost.25986        *.*                    LISTEN     

Это не дало мне PID, но, по крайней мере, показало, что на самом деле Apache удерживал порт 80. Затем я получил PID

$  sudo lsof -iTCP -sTCP:LISTEN
COMMAND     PID              USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
launchd       1              root   24u  IPv6 0x3917f1c4693aa457      0t0  TCP *:rfb (LISTEN)
launchd       1              root   25u  IPv4 0x3917f1c4693af43f      0t0  TCP *:rfb (LISTEN)
httpd     11654              root    5u  IPv6 0x3917f1c46be2d077      0t0  TCP *:http (LISTEN)
httpd     11655              _www    5u  IPv6 0x3917f1c46be2d077      0t0  TCP *:http (LISTEN)
httpd     11662              _www    5u  IPv6 0x3917f1c46be2d077      0t0  TCP *:http (LISTEN)
httpd     11663              _www    5u  IPv6 0x3917f1c46be2d077      0t0  TCP *:http (LISTEN)
httpd     11664              _www    5u  IPv6 0x3917f1c46be2d077      0t0  TCP *:http (LISTEN)
httpd     20907              _www    5u  IPv6 0x3917f1c46be2d077      0t0  TCP *:http (LISTEN)
httpd     20909              _www    5u  IPv6 0x3917f1c46be2d077      0t0  TCP *:http (LISTEN)
httpd     20910              _www    5u  IPv6 0x3917f1c46be2d077      0t0  TCP *:http (LISTEN)
httpd     20933              _www    5u  IPv6 0x3917f1c46be2d077      0t0  TCP *:http (LISTEN)

Используя PID, я теперь мог немного узнать о процессах, прежде чем убить его.

$  ps -ef 11654
  UID   PID  PPID   C STIME   TTY           TIME CMD
    0 11654     1   0  3:40PM ??         0:00.54 /usr/sbin/httpd -k start -e debug

И там это было. Похоже, что процесс Apache, который я запустил за день до того, как использовал отладочные флаги, не прерывался при подаче команды остановки в apachectl . Поэтому мне пришлось убить его вручную.

$  sudo killall httpd

Это позаботилось о "зомби" (хорошо, не зомби-процесс в теории ос, но все же не желая умирать). Перезапуск apache теперь работал нормально!

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .