nicht angemeldet
PHP als Modul arbeitet anders als FastCgi
Hi,
ich habe eine sehr umfangreiche PHP-Anwendung auf einen neuen Server geworfen. Dort hatte ich PHP als Modul laufen. Aber die Anwendung lief nicht.
Nach endlosen Tests, die schon sehr seltsam waren(Keine Fehlermeldungen trotz E_ALL), nichts zu finden. Dann kam ich auf die Idee mal PHP als fastcgi laufen zu lassen, und siehe da alles funktioniert wieder.
Beides PHP Version 5.2.9
Worin unterscheiden dich die beiden Möglichkeiten im Groben? So könnte ich vielleicht schneller die Ursache finden.
Timo
-
Das einem immer erst nach Absenden noch was einfallen muss:
ich habe eine sehr umfangreiche PHP-Anwendung auf einen neuen Server geworfen. Dort hatte ich PHP als Modul laufen. Aber die Anwendung lief nicht.
Die Anwendung lief auch bei der Modulversion, nur nicht komplett. Also nicht das es jemand falsch versteht.
Timo
-
Hi!
ich habe eine sehr umfangreiche PHP-Anwendung auf einen neuen Server geworfen. Dort hatte ich PHP als Modul laufen. Aber die Anwendung lief nicht.
"Läuft nicht" hat eine sehr geringe Aussagekraft für eine Lösungsfindung.
Nach endlosen Tests, die schon sehr seltsam waren(Keine Fehlermeldungen trotz E_ALL), nichts zu finden.
Was und wie hast du getestet? Und hast du überprüft, dass deine Änderungen auch angenommen wurden? Beispielsweise, ob deine Konfigurationsänderungen auch von phpinfo() angezeigt wurden?
Worin unterscheiden dich die beiden Möglichkeiten im Groben? So könnte ich vielleicht schneller die Ursache finden.
Im Groben gibt es keine Unterschiede, eher im Feinen. Selbst wenn dir jemand ein paar Unterschiede aufzählt, kann es bei dir an was ganz anderem liegen. Ich denke, du wirst nicht um ein Debugging drumrumkommen: mit Kontrollausgaben prüfen, ob alle Werte wie erwartet sind und die Abweichungen finden. Dann kann man auch gezielt weitersuchen und/oder helfen.
Lo!
-
Hi,
"Läuft nicht" hat eine sehr geringe Aussagekraft für eine Lösungsfindung.
Habe ich nach einer Lösung gefragt?
Würde ich das tun, könnte ich schon jetzt eine Vorhersage treffen:
1. Ich müsste aus >20.000 Zeilen Code aussuchen welchen davon ich hier poste.
2. Zur Antwort würde ich immer bekommen, hab ich dies, das, jenes auch gemacht
3. Es wäre sowas wie eine unendliche Gechichte, die am Ende darauf hinausläuft, hier zu hören ich kann nicht erwarten, dass hier Tonnen an Code analysiert werden.
Machen wir uns mal nichts vor,so ein Forum ist geeignet um konkrete Fragen zu stellen, um Fehleranalyse zu betreiben auf keinen Fall!
Was und wie hast du getestet? Und hast du überprüft, dass deine Änderungen auch angenommen wurden? Beispielsweise, ob deine Konfigurationsänderungen auch von phpinfo() angezeigt wurden?
Damit greifst du Punkt 2. schon vor.
Im Groben gibt es keine Unterschiede, eher im Feinen. Selbst wenn dir jemand ein paar Unterschiede aufzählt, kann es bei dir an was ganz anderem liegen. Ich denke, du wirst nicht um ein Debugging drumrumkommen: mit Kontrollausgaben prüfen, ob alle Werte wie erwartet sind und die Abweichungen finden. Dann kann man auch gezielt weitersuchen und/oder helfen.
Das ist doch schon eine Aussage, schade dachte wäre irgendwwie einr grober Unterschied vorhanden. Das wesentliche Problem ist, dass offensichtlich durch viele Includes der Rest der Seite nicht angezeigt wird bei der Modulversion, während bei der FastCgi schon.
Aber egal dann suche ich mal weiter.
Timo
-
Hi!
"Läuft nicht" hat eine sehr geringe Aussagekraft für eine Lösungsfindung.
Habe ich nach einer Lösung gefragt?Wenn du so fragst, nein, hast du nicht. Vielleicht hättest du aber trotzdem einen Hinweis darauf bekommen, wenn du mehr Details offenbart hättest.
Würde ich das tun, könnte ich schon jetzt eine Vorhersage treffen:
- Ich müsste aus >20.000 Zeilen Code aussuchen welchen davon ich hier poste.
Das würde ich nicht verlangen. Stattdessen versuche ich Hinweise zu geben, wie du dem Fehler oder Fehlern im Allgemeinen auf die Spur kommst. Mitunter fehlt es den Fragenden an grundlegendem Debugging-Fähigkeiten oder -Erfahrungen.
- Zur Antwort würde ich immer bekommen, hab ich dies, das, jenes auch gemacht
Den Satz versteh ich vom Sinn her nicht, aber egal.
- Es wäre sowas wie eine unendliche Gechichte, die am Ende darauf hinausläuft, hier zu hören ich kann nicht erwarten, dass hier Tonnen an Code analysiert werden.
Eben, deswegen würde ich beginnen, allgemeine Analysiertipps zu geben, jedoch die Analyse dir selbst zu überlassen und dir bei sich daraus ergebenden konkreten Fragen versuchen eine Antwort zu geben.
Machen wir uns mal nichts vor,so ein Forum ist geeignet um konkrete Fragen zu stellen, um Fehleranalyse zu betreiben auf keinen Fall!
Stimmt. Oft ist es eine konkrete Bedingung auf dem jeweiligen System, so dass sich Fehler nicht unbedingt anderswo nachvollziehen lassen. Das hast du ja schon selbst gemerkt, als auf dem einen System alles lief und auf dem anderen nicht. Manchmal ist es auch nur ein so allgemeiner Fehler, der auf jedem System auftritt.
Was und wie hast du getestet? Und hast du überprüft, dass deine Änderungen auch angenommen wurden? Beispielsweise, ob deine Konfigurationsänderungen auch von phpinfo() angezeigt wurden?
Damit greifst du Punkt 2. schon vor.Interessanter hätte ich ja eine fachliche Antwort gefunden.
Dass trotz E_ALL (wenn es wirksam gesetzt wurde) keine Meldungen ausgegeben werden, kann auch an @ liegen, die lokal Fehlermeldungen unterdrücken sollen.
Das wesentliche Problem ist, dass offensichtlich durch viele Includes der Rest der Seite nicht angezeigt wird bei der Modulversion, während bei der FastCgi schon.
Wenn du Includes vermutest, dann kann man sas testen, indem man ein
die('test');
vor den Include-Aufruf stellt und schaut, ob das test ausgegeben wird. Sollte es, wenn es das erste Include ist. Anschließend das die() schrittweise weiter nach hinten befördern, und wenn keine Ausgabe mehr erfolgt, liegt das Problem vermutlich am davor stehenden include.
Lo!
-
-
-
Hi,
Worin unterscheiden dich die beiden Möglichkeiten im Groben?
Die meisten Fallstricke lauern bei Funktionalitäten, die die "Verbindung" zwischen Webserver und PHP berühren - Setzen/Auslesen von HTTP-Headern beispielsweise.
Dass es an "vielen Includes" liegt, wie du aktuell vermutest, ist schwerer vorstellbar.
Natürlich sind Probleme mit Zugriffsrechten nichts ungewöhnliches - aber das sind i.a.R. keine "stummen" Fehler, mit error_reporting E_ALL sollten solche Sachen längst zum Vorschein gekommen sein, so sie denn wirklich ursächlich wären.MfG ChrisB
--
Light travels faster than sound - that's why most people appear bright until you hear them speak.