session_start blockt gesamtes script ohne fehler

[Griever]

Hallo.

Ich bin gerade am Verzweifeln und kann mir folgendes Problem nicht erklären:

<?php  
echo "Das geht ...<br>";  
session_start();  
echo "Das geht nicht mehr. Auch keine fehlermeldung oder dergleichen.";  
?>

oder

<?php  
error_reporting(E_ALL);  
session_start();  
echo "Das geht nicht mehr. Auch keine fehlermeldung oder dergleichen.";  
?>

oder

<?php  
error_reporting(E_ALL);  
@session_start();  
echo "Das geht nicht mehr. Auch keine fehlermeldung oder dergleichen.";  
?>

Also spätestens bei dem @session_start() hätte das 2te ja kommen müssen. kommt es aber nicht. Es kommt keine Fehlermeldung und es steht auch garnix in den logs.

Wer kann helfen??? o_o

[Tom]

Hello,

session_start();
echo "Das geht nicht mehr. Auch keine fehlermeldung oder dergleichen.";

Auch nicht nach dem Time-Out?
Kannst Du einen Log-Eintrag schreiben lassen per error_log()?

Ist das festgelegte Session-Verzeichnis für den PHP-Prozess beschreibbar?

Auf welchem OS läuft da welche PHP-Version in welcher Variante?

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Griever]

Auch nicht nach dem Time-Out?

Das script stoppt sofort. es folgt keine weitere ausführung des scripts.

Kannst Du einen Log-Eintrag schreiben lassen per error_log()?

Nope. geht leider nicht, da das script direkt beim ausführen von session_start() abgebrochen wird. error_log davor oder danach hat 0 effekt.

Ist das festgelegte Session-Verzeichnis für den PHP-Prozess beschreibbar?

Muss ich prüfen lasen. (ist nicht mein server)

Auf welchem OS läuft da welche PHP-Version in welcher Variante?

Muss ich ebenfalls nachfragen.

[Tom]

Hello,

Auch nicht nach dem Time-Out?

Das script stoppt sofort. es folgt keine weitere ausführung des scripts.

Wenn im Session-Verzeichnis nicht geschrieben werden kann, wartet das session_start() ggf. solange, bis es geht. Das kann ich jetzt nicht mit Bestimmtheit sagen, wie der Locking-Mechanismus genau arbeitet, zumal er vom OS bzw. Filesystem abhängig ist.

Kannst Du einen Log-Eintrag schreiben lassen per error_log()?

Nope. geht leider nicht, da das script direkt beim ausführen von session_start() abgebrochen wird. error_log davor oder danach hat 0 effekt.

Auch nicht, wenn Du register_shutdown_function() dafür verwendest, beim Abbruch des Scriptes noch eine Log-Funktion auszuführen?

Ist das festgelegte Session-Verzeichnis für den PHP-Prozess beschreibbar?

Muss ich prüfen lasen. (ist nicht mein server)

Auf welchem OS läuft da welche PHP-Version in welcher Variante?

Muss ich ebenfalls nachfragen.

Das ist allerdings wesentlich. Solltest Du aber erkennen können, wenn Du phpinfo() benutzt.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Tom]

Hello,

Du kannst das Session-Verzeichnis im Script ändern, bevor Du die session_start() aufrufst.

Es sollte aber außerhalb der Document Root liegen. Alles andere ist eine Sicherheitslücke und bestenfalls zu Testzwecken sinnvoll.

http://de3.php.net/manual/en/session.configuration.php#ini.session.save-path
http://de3.php.net/manual/en/function.ini-set.php

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Griever]

Das Problem ist Behoben.

Der Fehler lag darin, dass folgende 2 Werte in der Konfiguration nicht gesetzt waren:

session.save_path
session.cookie_httponly

Nach dem setzen dieser 2 werte funktioniert session_start wieder.

Das OS war übrigens Linux 10 :D

[Tom]

Hello,

Das Problem ist Behoben.

Fein!

Der Fehler lag darin, dass folgende 2 Werte in der Konfiguration nicht gesetzt waren:

session.save_path
session.cookie_httponly

Nach dem setzen dieser 2 werte funktioniert session_start wieder.

Wenn nichts gesetzt ist, nimmt Apache bzw. PHP seine defaults.
Bei session.save_path ist das '/tmp'

Darauf muss der PHP-Prozess dann aber Schreibrechte haben, bzw sich nicht per 'open_basedir' selbst beschränken. Eine Open-Basedir-Restriction wäre aber als Fehler aufgelaufen, während ein fehlendes Schreibrecht im Filesystem eventuell nur zu dem von Dir bemängelten Wartezustand führt.

session.cookie_httponly dürfte am Server überhaupt keine steuernden Auswirkungen haben, außer dass ein speziell markierter Cookie zum Client gesendet wird.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[tk]

Hallo Griever,

Der Fehler lag darin, dass folgende 2 Werte in der Konfiguration nicht gesetzt waren:

Du hättest dir vermutlich leichter getan, wenn du display_errors auf 1 gesetzt hättest um auftretende Fehler auch angezeigt zu bekommen.

Das OS war übrigens Linux 10 :D

"Linux 10" gibt es nicht.

Gruß,
Tobias