Apache 2.4 no se puede matar y no se puede detener en Windows Server

11

Tenemos dos Windows Server , uno de cada 2012 R2 y el otro en 2008 R2 que utiliza Apache HTTP Server ( httpd) 2.4 de proxy / modo de proxy inverso (el uso de ProxyPass, ProxyPassReversey la configuración de máquinas virtuales). Ambos servidores usan la compilación binaria Apache 2.4.27 x64 de Apache Haus.

Tenemos algunos scripts de respaldo ejecutándose en ambos servidores. Detienen todos los servicios (incluido Apache), luego hacen la copia de seguridad y reinician todos los servicios nuevamente.

Estas secuencias de comandos funcionan bien desde hace varios años (casi 4 años). Pero a partir de July 12, 2018, el comportamiento ahora es extraño. Los scripts de respaldo están haciendo su trabajo, deteniendo todos los servicios, haciendo el respaldo pero ahora, todos los servicios se reinician excepto Apache.

Después de investigar, descubrí que el servicio Apache 2.4.27 no se puede detener. Al usar la consola de Servicios e intentar detener manualmente el servicio, la consola muestra "Deteniendo" y no sucede nada.

Así que verifiqué los procesos en ejecución y vi que httpd.exese está ejecutando un proceso. Traté de matar ese proceso pero sin suerte.

Entonces, intenté:

taskkill /im "httpd.exe" /f /t

Y la salida es:

ERROR: The process with PID 560 (child process of PID 480) could not be terminated.
Reason: There is no running instance of the task.

Así que probé para matar el proceso con pskillSysinternals:

pskill -t 560

Y la salida es:

Copyright (C) 1999-2016  Mark Russinovich
Sysinternals - www.sysinternals.com

Process 5956 killed.

Pero esto es falso, ya que el httpdproceso siempre se está ejecutando.

Así que actualicé Apache de 2.4.27 a 2.4.34, pero el problema persiste. Lo único que debe hacer para desbloquear la situación es reiniciar todo el servidor.

Revisé las actualizaciones instaladas, y algunas de ellas se instalaron el July 11, 2018día anterior:

KB4338420
KB4338818
KB4339093
KB4338423

Así que supongo que el problema es de una de estas actualizaciones. Entonces, antes de desinstalarlos a todos, ¿hay alguien que tenga el mismo problema que yo, quiero decir que Apache 2.4 se vuelve imposible de matar y no se puede detener en Windows Server?

El gran problema es que si ese httpdproceso no se puede eliminar, Apache no se puede reiniciar ya que el puerto 80 ya está vinculado.

— SiZiOUS
fuente

3

El título lo hace sonar como un monstruo de película ...

— Trotski94

Se quería jajaja

— SiZiOUS

10

OK, entonces creo que estaba en el camino correcto.

Después de buscar en la Web las actualizaciones instaladas recientemente, el KB4338818 es el que causa problemas.

Esto está sucediendo para otros softwares, como FileZilla Server, como se detalla aquí .

¡Acabo de desinstalar esta actualización de seguridad y ahora Apache se puede iniciar / detener normalmente!

¡Así que espero que Microsoft arregle esto en una actualización posterior!

— SiZiOUS
fuente

Veo que has encontrado tu respuesta, pero me preguntaba si un reinicio del servidor también habría solucionado el problema. Además, si la actualización se aplicó mientras Apache no se estaba ejecutando, es posible que no haya causado los problemas.

— MonkeyZeus

Sí, como ya expliqué en la pregunta original, la única solución para desbloquear la situación es reiniciar todo el servidor ... ¡lo cual es una solución sucia!

— SiZiOUS

Lo siento, me perdí ese detalle, estaba un poco enterrado. Después de reiniciar, ¿el proceso no se pudo eliminar? Solo pregunto porque estoy ejecutando Windows 7 x64 con Apache en mi máquina local, pero todavía no he recibido KB4338818, así que quiero saber qué esperar.

— MonkeyZeus

1

No hay problema, no tienes que justificar tu comentario. :) Después de reiniciar, si configuró Apache para que se inicie automáticamente, funcionará. Pero cuando intentas detener el servicio (manualmente o usando scripts), el httpdproceso se congelará y no se podrá matar.

— SiZiOUS

3

Microsoft está lanzando KB4345459 para solucionar los problemas en Windows 7 y Windows 2008 Server.

https://support.microsoft.com/en-us/help/4345459/stop-error-0xd1-after-a-race-condition-occurs-in-windows-7-service-pac

— Fabricio Pocci
fuente

1

Parece que Microsoft está comenzando a solucionar el problema, hasta ahora solo para Server 2016 y Windows 10: https://support.microsoft.com/de-de/help/4345421/windows-10-update-kb4345421

— Hipersónico
fuente

1

KB4338831 parece solucionar el problema para Windows Server 2012 R2.

Esta actualización no relacionada con la seguridad incluye mejoras y correcciones que formaban parte de KB4338815 (lanzada el 10 de julio de 2018) y también incluye estas nuevas mejoras de calidad como una vista previa de la próxima actualización acumulativa mensual. Fuente: 18 de julio de 2018: KB4338831 (Vista previa del paquete acumulativo mensual)

Está disponible como una actualización recomendada en Windows Update.

— Alessandro Brandão
fuente

0

Creo que definitivamente estás en el camino correcto. Estaba teniendo un problema similar con Tomcat en un servidor de Windows. Sin embargo, tenía otro servidor con Tomcat que no experimentaba el problema, y la única gran diferencia que pude encontrar fue que el servidor en funcionamiento también tenía IIS instalado y ejecutándose en otros puertos. Como solución, intenté cargar IIS en el servidor con problemas configurando el sitio web predeterminado para que utilizara puertos no estándar y el problema parece haber desaparecido sin tener que desinstalar la actualización.

— Don Prezioso
fuente

1

OK ... lo retiro ... el truco de IIS solo parece funcionar algunas veces. El puerto 80 parece estar arreglado con la carga de IIS, pero el 443 solo funciona algunas veces. Además, para mí, la actualización ofensiva parece ser KB4338815. Al menos para mi servidor de producción, esto es lo único que se ejecuta en él, por lo que puedo reiniciar casi tan fácilmente como reiniciar Tomcat.

— Don Prezioso