Probleme mit Sessions im Trunk?

frank_nae 2008-09-20 09:45:46 UTC #1

Hallo zusammen,

ich setze den aktuellen Trunk ein. Nach einiger Zeit der Arbeit tritt
folgendes Problem auf:
Es wird z.B. ein Infologeintrag bearbeitet, alles nötige ist eingetragen
und ich klicke auf Speichern. Dann sind alle Felder im Popupfenster
geleert und ich kann keine Änderungen an Datensätzen mehr vornehmen.

Ich muß mich aus der Groupware ausloggen. Nach dem erneuten Login geht
wieder alles.
Leider passiert das recht unregelmäßig, so dass ich nicht nachvollziehen
kann, wann es auftritt.

Am Browser scheint es nicht zu liegen, die Probleme habe ich mit
Firefox, Opera und Konqueror.

Haben andere auch diese Probleme? Wie könnte man es beheben?

In diesem Zusammenhang: Kann ich denn auf die 1.4er Version downgraden,
obwohl die Datenbanken schon für die 1.6pre aktualisiert wurden? Oder
führt das zu Problemen?

Viele Grüße

This SF.Net email is sponsored by the Moblin Your Move Developer’s challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

Helmar_Suschka 2008-09-22 18:27:25 UTC #2

Hallo,

habe hier ähnliche Probleme mit dem Trunk, das betrifft alles, was sich die Groupware irgendwie “merken” muss.
Das äussert sich zum einen wie oben beschrieben in nicht möglichem Abspeichern von neuen oder geänderten Inhalten. Zum anderen gibt es ein “Einfrieren” bei Filtern z.B. im Adressbuch. Nach mehreren Aktionen lassen sich plötzlich die Filterkriterien nicht mehr ändern. Ändert man im Filter die Kategorie oder den Verteiler, landet man nach dem Reload der Seite wieder auf der vorigen Einstellung.
Das macht ein vernünftiges Arbeiten mit der eGw derzeit nahezu unmöglich.

Fragen:
Ist das Problem überhaupt schon (be/er)kannt? Da hier bislang niemand geantwortet hat, fürchte ich fast, nicht…
Gibt es einen Workaround, ohne den Trunk zu updaten? (Ich möchte aus dem 1.5er Trunk dann direkt auf die stabile 1.6 wechseln, der aktuelle Trunk ist bereits darüber hinaus, und ich weiss nicht, inwieweit ich dann die Datenbank wieder downgraden kann. Zudem lande ich beim testweisen Update derzeit in der bereits im Forum beschriebenen Endlosschleife mit der zu aktualisierenden header.inc.php, also keine greifbare Lösung.)

Ich habe in der Config bereits alle Session-Management-Varianten ausprobiert, php4, php4-restore und db - der fehler tritt jedes Mal unverändert auf. Nach 3-4 Aktionen ist Schluss, dann muss man sich aus- und wieder einloggen.

Ich hoffe, es ist eine baldige Lösung in Sicht.

Grüsse,
HS

Ralf_Becker_6 2008-09-22 19:32:21 UTC #3

Hi,

der Trunk ist nicht “über 1.6 hinaus” sondern noch immer vor der finalen
Version 1.6.

Seit einiger Zeit verwendet der Trunk immer den php Session restore, dh.
die Einstellung in der header.inc.php spielt keine Rolle mehr.

Hast Du einen anderen Sessionhandler als “files” in Deiner php.ini
konfiguriert?

Ralf

H. Suschka schrieb:

Hallo,

Frank Becker wrote:

Es wird z.B. ein Infologeintrag bearbeitet, alles nötige ist eingetragen
und ich klicke auf Speichern. Dann sind alle Felder im Popupfenster
geleert und ich kann keine Änderungen an Datensätzen mehr vornehmen.
Ich muß mich aus der Groupware ausloggen. Nach dem erneuten Login geht
wieder alles.
Haben andere auch diese Probleme? Wie könnte man es beheben?

habe hier ähnliche Probleme mit dem Trunk, das betrifft alles, was sich die
Groupware irgendwie “merken” muss.
Das äussert sich zum einen wie oben beschrieben in nicht möglichem
Abspeichern von neuen oder geänderten Inhalten. Zum anderen gibt es ein
"Einfrieren" bei Filtern z.B. im Adressbuch. Nach mehreren Aktionen lassen
sich plötzlich die Filterkriterien nicht mehr ändern. Ändert man im Filter
die Kategorie oder den Verteiler, landet man nach dem Reload der Seite
wieder auf der vorigen Einstellung.
Das macht ein vernünftiges Arbeiten mit der eGw derzeit nahezu unmöglich.

Fragen:
Ist das Problem überhaupt schon (be/er)kannt? Da hier bislang niemand
geantwortet hat, fürchte ich fast, nicht…
Gibt es einen Workaround, ohne den Trunk zu updaten? (Ich möchte aus dem
1.5er Trunk dann direkt auf die stabile 1.6 wechseln, der aktuelle Trunk ist
bereits darüber hinaus, und ich weiss nicht, inwieweit ich dann die
Datenbank wieder downgraden kann. Zudem lande ich beim testweisen Update
derzeit in der bereits im Forum beschriebenen Endlosschleife mit der zu
aktualisierenden header.inc.php, also keine greifbare Lösung.)

Ich habe in der Config bereits alle Session-Management-Varianten
ausprobiert, php4, php4-restore und db - der fehler tritt jedes Mal
unverändert auf. Nach 3-4 Aktionen ist Schluss, dann muss man sich aus- und
wieder einloggen.

Ich hoffe, es ist eine baldige Lösung in Sicht.

Grüsse,
HS

–
Ralf Becker
eGroupWare Training & Support ==> http://www.egroupware-support.de
Outdoor Unlimited Training GmbH [www.outdoor-training.de]
Handelsregister HRB Kaiserslautern 3587
Geschäftsführer Birgit und Ralf Becker
Leibnizstr. 17, 67663 Kaiserslautern, Germany
Telefon +49 (0)631 31657-0

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

Helmar_Suschka 2008-09-22 20:05:42 UTC #4

Hallo,
ok, mit dem Trunk habe ich wohl irgendwelche Nummern falsch interpretiert, sorry. Könnte also noch weiter updaten vor der 1.6, soweit ich um das Problem mit dem Anlegen der header.inc.php herumkomme (siehe Thread “Kann setup-admin nicht aufrufen, header-Amin will immer aktualisierung der header.inc.php” von Thomas Steinseifer).

Zum Session-Problem:
Der Handler ist auf files gestellt, der session_save_path ist schreibbar. Ich habe den Pfad auch schon entsprechend beobachtet: Wenn ich mich in die eGw einlogge, entsteht dort eine neue Datei, die dann mit jeder Aktion in der eGw ein wenig grösser wird. Logge ich mich aus, verschwindet die Datei. Ich gehe also davon aus, das in der Hinsicht alles soweit ok ist.

Gibt es weitere Ansätze, wo der Fehler herkommen könnte?

Grüsse,
H. Suschka

Ralf_Becker_6 2008-09-23 06:26:36 UTC #5

Hi,

also bei mir geht mit einem aktuellen Trunk der Session Handler "files"
ohne Probleme.

Bist Du evtl. auf einer Zwischenversion, die noch nicht stabil lief?
Mach doch einfach noch mal einen svn update bzw. lade den neuen Snapshot
runter.

Bzgl. Deines Header-Problems: Ich hab’ aber auch die Version im
header.inc.php.template wieder auf die alte (1.28) gesetzt, dh. das
Problem sollte, wenn Du aktuell bist, nicht mehr auftreten.

Ralf

H. Suschka schrieb:

ralfbecker wrote:

Hi,

der Trunk ist nicht “über 1.6 hinaus” sondern noch immer vor der finalen
Version 1.6.

Seit einiger Zeit verwendet der Trunk immer den php Session restore, dh.
die Einstellung in der header.inc.php spielt keine Rolle mehr.

Hast Du einen anderen Sessionhandler als “files” in Deiner php.ini
konfiguriert?

Hallo,
ok, mit dem Trunk habe ich wohl irgendwelche Nummern falsch interpretiert,
sorry. Könnte also noch weiter updaten vor der 1.6, soweit ich um das
Problem mit dem Anlegen der header.inc.php herumkomme (siehe Thread “Kann
setup-admin nicht aufrufen, header-Amin will immer aktualisierung der
header.inc.php” von Thomas Steinseifer).

Zum Session-Problem:
Der Handler ist auf files gestellt, der session_save_path ist schreibbar.
Ich habe den Pfad auch schon entsprechend beobachtet: Wenn ich mich in die
eGw einlogge, entsteht dort eine neue Datei, die dann mit jeder Aktion in
der eGw ein wenig grösser wird. Logge ich mich aus, verschwindet die Datei.
Ich gehe also davon aus, das in der Hinsicht alles soweit ok ist.

Gibt es weitere Ansätze, wo der Fehler herkommen könnte?

Grüsse,
H. Suschka

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

Helmar_Suschka 2008-09-23 11:11:29 UTC #6

Hallo,
Update hat geklappt, header.inc.php Problem tritt nicht mehr auf, bin jetzt auf Revision 26007.

Das andere Problem besteht leider weiter, ich habe es jetzt aber ein wenig näher analysieren können. Es liegt wohl u.a. an der Größe der Session-Datei.
Diese wächst beim Arbeiten mit der eGw sehr schnell an, besonders bei Filter- und Verschiebeoperationen im Adressbuch, aber auch bei jeder anderen Aktion wird sie ein Stück größer.
Sobald die Datei eine gewisse Größe erreicht (momentan ca. 2,2 - 3M), passiert das “Einfrieren” und es wird der Fehler

“Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 2923961 bytes) in Unknown on line 0”

ausgeworfen.

Ich hoffe, mit diesen Angaben kannst du dem Problem besser auf den Grund gehen.

Beste Grüsse,
H. Suschka

frank_nae 2008-09-23 13:57:31 UTC #7

Das andere Problem besteht leider weiter, ich habe es jetzt aber ein wenig
näher analysieren können. Es liegt wohl u.a. an der Größe der Session-Datei.
Diese wächst beim Arbeiten mit der eGw sehr schnell an, besonders bei
Filter- und Verschiebeoperationen im Adressbuch, aber auch bei jeder anderen
Aktion wird sie ein Stück größer.
Sobald die Datei eine gewisse Größe erreicht (momentan ca. 2,2 - 3M),
passiert das “Einfrieren” und es wird der Fehler

Hallo,
deine Beobachtungen kann ich bestätigen. Ich habe eben das Verhalten
nachvollzogen und einige Adressen geändert. Bei 2,7 MB war Schluß. Nur
aber erhalte ich keine Fehlermeldung wie du sie beschrieben hast.

Ich hoffe, mit diesen Angaben kannst du dem Problem besser auf den Grund
gehen.

Da wir die einzigen beiden sind, die sich derart “outen”, sollten wir
eine Selbsthilfegruppe gründen.

Sollten wir denn (am besten per PM) die Systemkonfig vergleichen?
Vielleicht fällt uns da etwas auf?

Beste Grüsse,
H. Suschka

Grüße

Frank Becker

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

frank_nae 2008-09-23 14:48:20 UTC #8

Hallo,
deine Beobachtungen kann ich bestätigen. Ich habe eben das Verhalten
nachvollzogen und einige Adressen geändert. Bei 2,7 MB war Schluß. Nur
aber erhalte ich keine Fehlermeldung wie du sie beschrieben hast.

Hatte das Logging ausgeschaltet:
[Tue Sep 23 16:24:04 2008] [error] [client 192.168.100.150] PHP Fatal
error: Allowed memory size of 33554432 bytes exhausted (tried to
allocate 2097017 bytes) in Unknown on line 0, referer:
http://telnix.local/egroupware/etemplate/process_exec.php?menuaction=addressbook.addressbook_ui.edit

Server:
Apache
Server version: Apache/2.2.3
Server built: Jan 31 2008 08:45:16

PHP
PHP 5.2.0-8+etch11 (cli) (built: May 10 2008 10:35:46)
Copyright © 1997-2006 The PHP Group
Zend Engine v2.2.0, Copyright © 1998-2006 Zend Technologies
with eAccelerator v0.9.5.2, Copyright © 2004-2006 eAccelerator, by
eAccelerator

memory_size=128M

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

Helmar_Suschka 2008-09-23 15:07:25 UTC #9

Hallo,
deine Beobachtungen kann ich bestätigen. Ich habe eben das Verhalten
nachvollzogen und einige Adressen geändert. Bei 2,7 MB war Schluß. Nur
aber erhalte ich keine Fehlermeldung wie du sie beschrieben hast.

Hatte das Logging ausgeschaltet:
[Tue Sep 23 16:24:04 2008] [error] [client 192.168.100.150] PHP Fatal
error: Allowed memory size of 33554432 bytes exhausted (tried to
allocate 2097017 bytes) in Unknown on line 0, referer:
http://telnix.local/egroupware/etemplate/process_exec.php?menuaction=addressbook.addressbook_ui.edit

Server:
Apache
Server version: Apache/2.2.3
Server built: Jan 31 2008 08:45:16

PHP
PHP 5.2.0-8+etch11 (cli) (built: May 10 2008 10:35:46)
Zend Engine v2.2.0, Copyright © 1998-2006 Zend Technologies
with eAccelerator v0.9.5.2, Copyright © 2004-2006 eAccelerator, by eAccelerator

memory_size=128M

Ja, das ist im Prinzip der gleiche Typ Fehler wie bei mir.

Lokal läuft ein Debian SID mit aktuellen Apache/PHP-Paketen, Memory-Limit 32MB für die eGroupware (sollte reichen).
Auf dem Webserver, auf dem das gleiche Problem auftritt, läuft Debian ETCH, ebenfalls aktuell gehalten, mit identischen Speichereinstellungen.
Session-Management per FILES ist in beiden Fällen aktiviert, der Fehlerhergang ist identisch. Die sonstigen Configs sind weitestgehend Standard.

Wenn man im Forum nach “memory size exhausted” sucht, tauchen ähnliche Probleme von früher auf, wir sind also nicht die Ersten.
Ich warte mal noch auf eine erneute Rückmeldung von Ralf Becker, vielleicht hat er einen schnellen Kniff zur Lösung parat.

Beste Grüsse,
H. Suschka

frank_nae 2008-09-23 15:24:23 UTC #10

Einen habe ich noch

Ich habe schon seit einiger Zeit eGW zusätzlich zu Test- und
Backupzwecken eGW in einer virtuellen Maschine am laufen.

Gleiches System wie der Hauptserver. Aaaaaaaber:

in der php.ini am Hauptserver steht memory_limit=128M,
in der virtuellen Maschine jedoch memory_limit=48M

Jetzt kommts: Das Session-file kann beim Arbeiten 4,4 MB groß werden.
2,5-fach mehr Speicher aber nur die halbe Reichweite?

Wie passt das zusammen?

Es grüßt euch
Frank Becker

der jetzt morgen aufpassen muß, dass die Mitarbeiter sich regelmäßig
ausloggen.

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

frank_nae 2008-09-23 23:31:10 UTC #11

memory_size=128M

So ich glaube die Nachtschicht hat sich gelohnt.

Ich habe dauernd in der php.ini rumgeschraubt und nicht beachtet, dass
in der aktuellen Version auch Einträge in der .htaccess gemacht wurden.

Da steht nämlich
php_value memory_limit 16M

Ich habe das jetzt auskommentiert und dann gilt nämlich das was in der
php.ini steht. Jetzt kann ich klicken bis das Sessionfile 14MB groß ist.
Das reicht mir erst einmal, jetzt schalte ich ab.

Noch ein Tipp an alle
Sehr hilfreich war ein AddOn für den Firefox - Selenium IDE. Damit kann
man Mausklicks aufzeichnen und beliebig oft wiederholen. Während ich das
hier schreibe, klickt das Script munter weiter und das Session-File ist
jetzt bei 17MB.

Jetzt höre ich aber wirklich auf.

HS (wie heißt du eigentlich mit Vornamen?), ich hoffe das damit auch
Deine Probleme gelöst sind.

Grüße
Frank Becker

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

Helmar_Suschka 2008-09-24 12:18:18 UTC #12

Ich habe dauernd in der php.ini rumgeschraubt und nicht beachtet, dass
in der aktuellen Version auch Einträge in der .htaccess gemacht wurden.
Da steht nämlich
php_value memory_limit 16M

Das stand bei mir schon 32M drin, setze es meist auf diesen Wert.

HS (wie heißt du eigentlich mit Vornamen?), ich hoffe das damit auch
Deine Probleme gelöst sind.

Nun ja, das verschiebt den Zeitpunkt des Einfrierens ein wenig nach hinten… löst aber nicht das eigentliche Problem der riesigen Session-Dateien. Einige meiner Kunden müssen viel im Adressbuch sortieren und filtern (Kategorien, Verteiler, etc.), da sind sie ganz schnell an der Grenze angelangt, denn bei solchen Aktionen springt das Session-File z.T. um 300 - 500 KB pro Vorgang nach oben.

Gibt’s dazu eventuell noch Rückmeldungen von Entwicklerseite? Wäre schön zu wissen, ob und wann das Problem ggf. in Angriff genommen wird.

Beste Grüsse,
Helmar Suschka