session fehlermeldung

[Tobias Otto]

Hallo ich bekomme beim seitenaufruf solgende fehlermeldung

Warning: session_start() [function.session-start]: open(/var/tmp/sess_1f81f7e4ebe0afa812a1b120a663f5ab, O_RDWR) failed: File too large (27) in /mnt/web3/12/32/5896432/htdocs/prinzdeluxe/index.php on line 2

Warning: session_start() [function.session-start]: Cannot send session cookie - headers already sent by (output started at /mnt/web3/12/32/5896432/htdocs/prinzdeluxe/index.php:2) in /mnt/web3/12/32/5896432/htdocs/prinzdeluxe/index.php on line 2

Warning: session_start() [function.session-start]: Cannot send session cache limiter - headers already sent (output started at /mnt/web3/12/32/5896432/htdocs/prinzdeluxe/index.php:2) in /mnt/web3/12/32/5896432/htdocs/prinzdeluxe/index.php on line 2

an was kann dies liege? Am Freitag gings noch ohne Probleme. Habe auch nicht geändert.

Danke

[Miri]

Hallo ich bekomme beim seitenaufruf solgende fehlermeldung

hoi

Warning: session_start() [function.session-start]: open(/var/tmp/sess_1f81f7e4ebe0afa812a1b120a663f5ab, O_RDWR) failed: File too large (27) in /mnt/web3/12/32/5896432/htdocs/prinzdeluxe/index.php on line 2

wie da steht: file too large... ieine Datei is zu groß geworden...

Danke

Bitte

[Tobias Otto]

Hallo, und wie kann dích nun dieses problem beheben???

[Tom]

Hello,

Hallo, und wie kann dích nun dieses problem beheben???

Indem Du das Memory Limit raufsetzt.
Außerdem könnte es helfen, in der Konfiguration (php.ini) eine Änderung vorzunehmen:

register_long_arrays = off

sollte das noch auf ON stehen bei Dir, könnte es sein, dass Du noch viel Speicher mit redundanten Daten vergeudet hast. Es handelt sich dabei um die guten alten $HTTP_*_VARS-Arrays, die man i.d.R. nicht mehr braucht heute.

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Tobias Otto]

Hallo,

leider bin ich bei der Strato, und kann da an den servereinstellungen nix ändern, oder??

[Tom]

Hello,

leider bin ich bei der Strato, und kann da an den servereinstellungen nix ändern, oder??

Doch, über .htaccess kann man Environment-Variablen improtieren und über eine eigene php.ini in den Scriptverzeichnissen kann man die Einstellungen verändern.

Außerdem kannst Du ggf. im Script auch mit ini_set() etwas bewirken.
Das Memory-Limit kann man geggf. hochsetzen damit.
Das muss dann aber _vor_ dem session_start() geschehen.

Ich habe eben voller Schreck festgestellt, dass ich nach dem Neuaufbau meines Testservers die php.ini auch noch nocht wieder eingestellt habe...

[HTTP_SESSION_VARS] => Array
                (
                    [script] => kontrolle.php
                )

Die Session-Variablen werden auch redundant ins Script geholt und wenn jetzt zu allem Überfluss auch noch register_globals auf ON steht, dann hast Du sie sogar dreimal im Speicher.

Dass das Script da abschmiert mit zuwenig Memory ist logisch.
Es handelt sich bei den drei Vraiablensammlungen um drei unterschiedliche, die während der Laufzeit nichts miteinander zu tun haben. Wenn Du nun fließig $_SESSION mit werten befüllst, bekommen die beiden anderen Möglichkeiten nichts davon mit. Endet das Script, werden die Sessionvariablen brav in die Datei geschrieben.

Wenn Du die Session nun wieder aufrufst, werden

• die "kleinen" Scriptvariablen aus der Session erzeugt und befüllt
• das Array $HTTP_SESSION_VARS angelegt und gefüllt
• das Array $_SESSION angelegt und gefüllt.

Das bedeutet, Du hast dann plötzlich bis zu knapp dreimal soviel Speicherbedarf, wie beim letzten Beenden des Scriptes

Beinahe habe ich es vergessen.

Kannst Du uns temporär eine URL mit einer phpinfo() zur Verfügung stellen zum Anschauen?

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Tom]

Hello,

spannende Sache...
PHP gibt den Fehler scheinbar nur weiter.

und zwar in mod_files.c

} else {
  php_error_docref(NULL TSRMLS_CC, E_WARNING, "open(%s, O_RDWR) failed: %s (%d)", buf,
     strerror(errno), errno);
 }

Er stammt vermutlich aus der nlibc.h

http://www-zeuthen.desy.de/apewww/APE/software/nlibc/html/errno_8h-source.html
http://www-zeuthen.desy.de/apewww/APE/software/nlibc/html/nlibc_8h.html

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Tom]

Hello,

spannende Sache...

Der Fehler scheint gehäuft bei der Benutzung von rsync aufzutreten.
Damit wäre er also auf jeden Fall beim Provider zu suchen...
Datensicherung, Mirror oder ähnlichem.

http://de.wikipedia.org/wiki/Rsync

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Tom]

Hello,

PHP gibt den Fehler (27) scheinbar nur vom OS weiter.

Der aufgetretene Fehler stammt also nicht direkt von der Session, auch wenn er während einer Session-Initialisierung aufgetreten ist und in diesem Zusammenhang gemeldet wurde.
Er tritt übrigens, soweit sich das bisher mittels Google feststellen lässt, bei Stratokunden auf.

Es wäre auch möglich gewesen, dass PHP vorher prüft, wieviel Speicher es für das "Auspacken" der Session-Datei benötigt, und dies dann als "Datei zu groß" meldet.

Das ist aber nicht der Fall. PHP prüft vorher nicht und lässt einen ins Messer rennen.

Die Anomalie bei den Sessions ist mit der nächsten Version (PHP 6) angeblich sowieso beseitigt. Dann werden gespeicherte Sessions beim "Wiederauspacken" nicht mehr den ca. dreifachen Speicherbedarf haben können, weil es kein "Register Globals" und auch keine "Long-Arrays" ($HTTP_*_VARS) mehr geben wird.

Und wann PHP wegen Speichermangels abschmiert, ist auch nicht einfach vorhersehbar. Am nächsten kommt man dem Moment, wenn man

memory_get_usage(false)
 + memory_get_usage(true)
 - memory_limit                # kann mit K, M, G versehen sein. vorher umrechnen!
 -------------------------
 ~ Rest des zur Verfügung stehenden Speichers

rechnet.

Bei meinen Versuschen mit 4M Memory-Limit (damit es nicht so lange dauert) waren ca. 79.000 Bytes mehr vorhanden, als es sich aus den obigen Größen ausrechnen ließ. Ein Blick in den Source-Code für die Speicherverwaltung könnte da sicher mehr Aufschluss geben.

Das verwendete "Testscript" liegt unter
http://selfhtml.bitworks.de/session_memory/session_memory_limit.php.txt

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Sven Rautenberg]

Moin!

Hallo, und wie kann dích nun dieses problem beheben???

Indem Du das Memory Limit raufsetzt.

Wow, das mußt du mir mal kausal erklären: Eine Fehlermeldung, die sagt, dass die Session-Datei nicht geöffnet werden kann, weil sie zu groß ist, soll behoben werden, indem man den benutzbaren RAM-Speicher des Skripts erhöht!

Welcher Zusammenhang soll denn da bestehen?

- Sven Rautenberg

[Tom]

Hello,

ich habe ausgetestet, welche Fehlermeldung bei der von mir hier angeprangerten Speicherverschwendung und dem Erreichen des Memory-Limits ausgegeben wird:

Fatal error:  Allowed memory size of 4194304 bytes exhausted (tried to allocate 2359297 bytes) in /home/thomas/web/php4/Sessions/session_memory/session_memory_limit.php on line 47

...wäre also ein Beispiel dafür.

Scriptvariablen (also die importierten) werden bei memory_get_usage(false) nicht mitgerechnet, sondern nur bei memory_get_usage(true);

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Tom]

Hello,

Scriptvariablen (also die importierten) werden bei memory_get_usage(false) nicht mitgerechnet, sondern nur bei memory_get_usage(true);

Kommando zurück...
Aber irgendwas passt da nicht mit der Beschreibung von memory_get_usage().

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Sven Rautenberg]

Moin!

Scriptvariablen (also die importierten) werden bei memory_get_usage(false) nicht mitgerechnet, sondern nur bei memory_get_usage(true);

Kommando zurück...
Aber irgendwas passt da nicht mit der Beschreibung von memory_get_usage().

Erklärst du trotzdem nochmal, wieso du Messungen an der RAM-Nutzung vornimmst, obwohl die OP-Fehlermeldung ganz deutlich von einer zu großen DATEI spricht?

- Sven Rautenberg