O Apache não será iniciado no Mountain Lion. Sintaxe OK. O que está acontecendo?

Question

Ao longo de dois dias, eu estava fazendo muitas alterações na minha configuração do Apache. Às vezes as mudanças não pareciam ser captadas, e sempre foi o caso de eu ter de alguma forma bagunçado a sintaxe do arquivo de configuração, algo que apachectl -t sempre mostraria. O syslog também mostrará mensagens de erro relativas ao respawning httpd.

No dia seguinte, precisei fazer algumas alterações adicionais e observei que elas não foram selecionadas pelo Apache. Eu queria ver os erros no error_log do apache, mas não havia nada para ver. Removê-los e reiniciar o apache não fez nada. Os arquivos não foram sequer recriados!

Então, claro, verifiquei a sintaxe novamente e apachectl -t cospe Syntax OK . Nada de errado lá, parece. Então eu verifico meu syslog, e ele está cheio de erros relativos ao 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

Parar, iniciar, reiniciar com o apachectl não fez absolutamente nada. Mas eu estava conseguindo acessar o host local. Então, o que estava acontecendo?

    

Answer 1

Quando percebi que podia acessar o host local na porta 80, mesmo tendo emitido apachectl stop , o caminho para a iluminação estava claro. Eu precisava descobrir o que realmente estava ocupando a porta 80 e matá-lo.

Primeiro eu verifiquei o que estava segurando nele

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     

Isso não me deu o PID, mas pelo menos me mostrou que, na verdade, era o Apache que segurava a porta 80. Em seguida, peguei os PIDs

$  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)

Usando o PID, agora eu poderia aprender um pouco sobre os processos antes de matá-lo

$  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

E aí estava. Parece que o processo do Apache que eu iniciei no dia anterior usando sinalizadores de depuração não estava sendo eliminado ao emitir o comando stop para apachectl . Portanto, eu tive que matá-lo manualmente.

$  sudo killall httpd

Isso cuidou do "zumbi" (OK, não é um processo zumbi na teoria dos sistemas operacionais, mas ainda não quer morrer). Reiniciar o apache agora funcionou bem!