Wer einen Managed Server bei 1&1 betreibt, der ist vor einigen Wochen in den „Genuss“ eines dicken Updates des Apache auf 2.2 und der unterliegenden Linux-Distribution auf Debian Squeeze. Wer vor dem Update den so genannten „Performance Server“ verwendete, sollte diesen jetzt schleunigst deaktivieren, um keine Probleme zu bekommen bzw. um bestehende zu lösen.
Der „Performance Server“ stellt bzw. vielmehr stellte eine Möglichkeit dar, einige Servereigenschaften des Apache feinzutunen. Das war eine feine Sache, konnte man doch so z.B. die maximal in der php.ini konfigurierbare max_execution_time einstellen, und noch ein paar andere Dinge.
Nun war es aber so, dass unser Server seit dem Update dazu neigte, PHP-Prozesse mitunter nicht korrekt abzuräumen. Es endete damit, dass man in der „top“-Prozessliste bis zu 20 „php4exe“ oder auch „php5exe“ Prozesse herumliegen sah – offensichtlich nicht korrekt beendete PHP-Prozesse. Mitunter saute der Server sich derart zu, dass er keine HTTP-Anfragen von außen mehr beantwortete. Schaffte man es in dem Moment noch per SSH auf die Maschine, löste „killall php4exe“ das Problem und der Server antwortete wieder auf HTTP-Anfragen. Kam man allerdings nicht mehr auf die Kiste – nun, dann durfte der 1&1 Support den Server hart rebooten.
Wieso blieben die PHP-Prozesse also stehen? Nun, schauen wir doch einmal in die phpinfo()-Ausgabe. Was steht da?
max_execution_time 50000
Wie bitte?! 50.000 Sekunden? Das sind 13.8 Tage Stunden! (Danke für den Korrekturhinweis. Das war auch mehr ein Tipp- als ein Denkfehler.)
Flugs die php.ini definiert:
max_execution_time = 60
Und siehe da – nichts sehen wir: Keine Änderung, weiterhin 50.000. Also, Ersatzmethode .htaccess:
php_value max_execution_time 60
Saustark: Sobald die .htaccess diese Einstellung enthält wirft der Apache einen Error 500. Übrigend auch bei jeder anderen Forum von php_value oder php_flag Einstellungen. Danke, 1&1!
Ich habe daraufhin eine längere und unzufriedene Support-Anfrage an 1&1 gestellt – nach einigen konstruktiven Beispielen endete diese mit folgenden Worten meinerseits:
[…]
Lange Rede, kurzer Sinn:
(1) Die Default-Einstellung für max_execution_time ist Unfug.
(2) Dass die php.ini nicht geparst wird, ist ein starkes Stück.
(3) Dass eine php_value-Eintragung in der .htaccess zu einem Error 500 führt, ist haarsträubend.
Bitte korrigieren Sie diese Punkte so bald wie möglich. Ich bin mir sicher, dass davon nicht nur unser Managed Server betroffen ist, sondern sicherlich auch die Managed Server von vielen anderen Kunden, deren Server identisch (fehl-)konfiguriert sind.
Mit freundlichem Gruß und Dank im voraus
Die Antwort kam 10 Stunden später, an einem Samstag (!) um 7:10 Uhr morgens (!!):
vielen Dank für Ihre E-Mail. Diese beantworten wir Ihnen gerne.
Da das System auf Debian Squeze mit Apache 2.2 upgedated wurde ist ein Eintragen der Limits zwingend in der php.ini erforderlich.
Durch das Update wurde der Performance Server obsolet. Mit eingeschaltetem Performance Server funktioniert kein Parsing Aufruf.
Der Apache Webserver in Version 2.2 nimmt es bei falscher Syntax (z.B.: Limits in .htaccess) sehr genau. Somit bitten wir Sie, den Performance Server in den Server-Diensten des 1&1 Control-Centers auszuschalten.
Danach sollten die Eintragungen wie oben angesprochen ausgeführt werden.
Wir freuen uns, wenn wir Ihre Fragen zu Ihrer Zufriedenheit beantwortet haben.
Bei weiteren Fragen sind wir gerne für Sie da.
Mit freundlichen Grüßen
P****** S******
OK, das ist doch mal eine Aussage. Ich möchte das gerne bewusst spitzüngig paraphrasieren:
Der Performance Server ist veraltet. Wir wissen, dass die früheren Einstellungen zu Problemen z.B. beim Parsing der php.ini führen – haben aber davon abgesehen, sie auf allen geupdateten Servern per Default zu deaktivieren. Machen Sie das doch bitte selbst!
Anschließend dürfen Sie diese Konfigurationsoption im 1&1 Control Center getrost ignorieren. Fragen Sie uns aber bitte nicht, warum dieser Punkt dort noch zu finden ist, wenn man ihn sowieso deaktivieren und deaktiviert lassen sollte.
Und siehe da: Seit ich den Performance Server deaktiviert habe, erscheinen in der Prozessliste keine „php4exe“- und „php5exe“-Prozesse mehr, sondern nur noch „php4“ und „php5“ Prozesse. Und ich kann die max_execution_time wieder auf sinnvolle Werte herunterschrauben.
Danke, 1&1! Gut gemacht! Genau so wünsche ich mir ein Update!
Not.
Konstruktive Anweisung für ebenfalls Betroffene, die es per Google hierher geschafft haben: Checkt bitte mal mit „top“ die Prozessliste Eures Managed Servers. Wenn dort Prozesse namens „php4exe“ und „php5exe“ erscheinen, habt Ihr wahrscheinlich den Performance Server aktiviert. Knipst das Ding aus und Ihr seid eine Menge Sorgen los. … Längst nicht alle, aber viele.
Danke für die Hinweise.
Wir haben uns seit den letzten Updates der vergangenen 2 Wochen ebenfalls mehrfach mit dem Support von 1&1 herumschlagen müssen – mit der Aussage, es sei alles ok und würde funktionieren!
Nur wenn man dann hartnäckig bleibt, geht’s doch irgendwann mal weiter.
Danke für die zusätzlichen Hinweise in diesem zweiten Bericht! Haben wir sicherheitshalber auch noch geändert.
Das Systemupdate hatte wirklich sehr unerfreuliche Begleiterscheinungen. Wir sind schon sehr lange bei 1&1 und hatten so etwas in dieser Form noch nicht erlebt.
Kleine Korrektur:
50000 sec sind 13,8 Stunden – nicht Tage.
Grüße
Ausgezeichneter Artikel!
Wie „knipse“ ich den „Performance Server“ aus?
Im Control-Center, rechts unter „Server-Dienste“. Ich kann nicht genau sagen, welche dieser Einstellungen das Problem exakt verursacht hat, aber momenten läuft mein Server wieder mit Standardeinstellungen.