Apache 2.4 è immutabile e non può essere arrestato su Windows Server

Abbiamo due Windows Server , uno in 2012 R2 e l'altro in 2008 R2 che utilizza Apache HTTP Server ( httpd) 2.4 in proxy / modalità reverse proxy (uso di ProxyPass, ProxyPassReversee host virtuali configurazione). Entrambi i server utilizzano Apache 2.4.27 x64 build binaria di Apache Haus.

Abbiamo alcuni script di backup in esecuzione su entrambi i server. Arrestano tutti i servizi (incluso Apache), quindi eseguono il backup e riavviano nuovamente tutti i servizi.

Questi script funzionano bene da diversi anni (quasi 4 anni). Ma a partire da July 12, 2018ora il comportamento è strano. Gli script di backup stanno facendo il loro lavoro, arrestando tutti i servizi, eseguendo il backup ma ora tutti i servizi vengono riavviati tranne Apache.

Dopo aver esaminato, ho scoperto che il servizio Apache 2.4.27 non può essere arrestato. Quando si utilizza la console dei servizi e si tenta di arrestare manualmente il servizio, la console mostra "Arresto" e non accade nulla.

Quindi ho controllato i processi in esecuzione e ho visto che un httpd.exeprocesso è in esecuzione. Ho provato ad uccidere quel processo ma senza fortuna.

Quindi, ho provato:

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

E l'output è:

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

Quindi ho provato ad interrompere il processo con pskillda Sysinternals:

pskill -t 560

E l'output è:

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

Process 5956 killed.

Ma questo è falso, poiché il httpdprocesso è sempre in esecuzione!

Quindi ho aggiornato Apache dalla 2.4.27 alla 2.4.34, ma il problema rimane. L'unica cosa da fare per sbloccare la situazione è riavviare l'intero server.

Ho controllato gli aggiornamenti installati e alcuni di essi sono stati installati il July 11, 2018giorno prima:

• KB4338420
• KB4338818
• KB4339093
• KB4338423

Quindi presumo che il problema provenga da uno di questi aggiornamenti. Quindi, prima di disinstallarli tutti, c'è qualcuno che ha lo stesso problema, intendo Apache 2.4 che diventa invendibile e non può essere fermato su Windows Server?

Il grosso problema è che se questo httpdprocesso non può essere interrotto, Apache non può essere riavviato poiché la porta 80 è già associata.

OK, quindi penso di essere sulla buona strada.

Dopo aver cercato sul Web gli aggiornamenti installati di recente, KB4338818 è quello che causa problemi.

Questo sta accadendo per altri software, come FileZilla Server, come dettagliato qui .

Ho appena disinstallato questo aggiornamento di sicurezza e ora Apache può essere avviato / arrestato normalmente!

Quindi spero che Microsoft lo risolva in un aggiornamento successivo!

Microsoft sta rilasciando KB4345459 per risolvere i problemi in Windows 7 e Windows 2008 Server.

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

Sembra che Microsoft stia iniziando a risolvere il problema, fino ad ora solo per Server 2016 e Windows 10: https://support.microsoft.com/de-de/help/4345421/windows-10-update-kb4345421

KB4338831 sembra risolvere il problema per Windows Server 2012 R2.

Questo aggiornamento non relativo alla sicurezza include miglioramenti e correzioni che erano parte della KB4338815 (rilasciata il 10 luglio 2018) e include anche questi nuovi miglioramenti della qualità come anteprima del prossimo aggiornamento cumulativo mensile. Fonte: 18 luglio 2018 — KB4338831 (anteprima dell'aggiornamento cumulativo mensile)

È disponibile come aggiornamento consigliato su Windows Update.

Penso che tu sia decisamente sulla buona strada. Avevo un problema simile con Tomcat su un server Windows. Avevo un altro server con Tomcat che non stava riscontrando il problema, e l'unica grande differenza che riuscivo a trovare era che il server funzionante aveva anche IIS installato e funzionante su altre porte. Come soluzione ho provato a caricare IIS sul server problematico impostando il sito Web predefinito in modo che utilizzasse porte non standard e il problema sembra essere scomparso senza dover disinstallare l'aggiornamento.