Apache 2.4 est impossible à tuer et ne peut pas être arrêté sur Windows Server

Nous avons deux serveurs Windows , l'un en 2012 R2 et l'autre en 2008 R2 qui utilise Apache HTTP Server ( httpd) 2.4 en mode proxy / proxy inverse (utilisation de ProxyPass, ProxyPassReverseet configuration des hôtes virtuels). Les deux serveurs utilisent la version binaire Apache 2.4.27 x64 d'Apache Haus.

Nous avons des scripts de sauvegarde en cours d'exécution sur les deux serveurs. Ils arrêtent tous les services (y compris Apache) puis effectuent la sauvegarde et redémarrent tous les services à nouveau.

Ces scripts fonctionnent bien depuis plusieurs années (près de 4 ans). Mais à partir de là July 12, 2018, le comportement est maintenant étrange. Les scripts de sauvegarde font leur travail, arrêtent tous les services, effectuent la sauvegarde mais maintenant, tous les services sont redémarrés sauf Apache.

Après enquête, j'ai constaté que le service Apache 2.4.27 ne pouvait pas être arrêté. Lorsque vous utilisez la console Services et essayez d'arrêter manuellement le service, la console affiche «Arrêt» et rien ne se produit.

J'ai donc vérifié les processus en cours d'exécution et j'ai vu qu'un httpd.exeprocessus était en cours d'exécution. J'ai essayé de tuer ce processus mais sans succès.

J'ai donc essayé:

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

Et la sortie est:

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

J'ai donc testé pour tuer le processus avec pskillde Sysinternals:

pskill -t 560

Et la sortie est:

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

Process 5956 killed.

Mais c'est faux, car le httpdprocessus est toujours en cours!

J'ai donc mis à jour Apache de 2.4.27 à 2.4.34, mais le problème persiste. La seule chose à faire pour débloquer la situation est de redémarrer l'ensemble du serveur.

J'ai vérifié les mises à jour installées, et certaines d'entre elles ont été installées le July 11, 2018jour précédent:

• KB4338420
• KB4338818
• KB4339093
• KB4338423

Je suppose donc que le problème provient d'une de ces mises à jour. Donc, avant de les désinstaller tous, y a-t-il quelqu'un qui a le même problème que moi, je veux dire qu'Apache 2.4 devient impossible à tuer et ne peut pas être arrêté sur Windows Server?

Le gros problème est que si ce httpdprocessus ne peut pas être tué, Apache ne peut pas être redémarré car le port 80 est déjà lié.

OK, donc je pense que j'étais sur la bonne voie.

Après avoir recherché sur le Web les mises à jour récemment installées, le KB4338818 est celui qui pose problème.

Cela se produit pour d'autres logiciels, comme FileZilla Server, comme détaillé ici .

Je viens de désinstaller cette mise à jour de sécurité et maintenant Apache peut être démarré / arrêté normalement!

J'espère donc que Microsoft corrigera cela dans une mise à jour ultérieure!

Microsoft publie KB4345459 pour résoudre les problèmes dans Windows 7 et Windows 2008 Server.

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

Il semble que Microsoft commence à résoudre le problème, jusqu'à présent uniquement pour Server 2016 et Windows 10: https://support.microsoft.com/de-de/help/4345421/windows-10-update-kb4345421

KB4338831 semble résoudre le problème pour Windows Server 2012 R2.

Cette mise à jour non liée à la sécurité comprend des améliorations et des correctifs qui faisaient partie du KB4338815 (publié le 10 juillet 2018) et inclut également ces nouvelles améliorations de la qualité en tant qu'aperçu de la prochaine mise à jour du correctif cumulatif mensuel. Source: 18 juillet 2018 - KB4338831 (aperçu du correctif cumulatif mensuel)

Il est disponible en tant que mise à jour recommandée sur Windows Update.

Je pense que vous êtes définitivement sur la bonne voie. J'avais un problème similaire avec Tomcat sur un serveur Windows. J'avais un autre serveur avec Tomcat qui ne rencontrait pas le problème cependant, et la seule différence majeure que j'ai pu trouver était que le serveur de travail avait également IIS installé et fonctionnant sur d'autres ports. Comme solution de contournement, j'ai essayé de charger IIS sur le serveur problématique en configurant le site Web par défaut afin qu'il utilise des ports non standard et le problème semble avoir disparu sans avoir à désinstaller la mise à jour.