phpMyAdmin Probleme(?)

[flywalker]

Hallo,

habe auf meinem neuen Server folgende Probleme mit phpMyAdmin

1. Wenn ich auth_type auf cookie stelle, dann tritt folgendes Problem auf:
ich logge mich ein, alles funktioniert ohne Probleme. Nach einiger Zeit Inaktivität kriege ich wieder das Login-Formular angezeigt (was ja auch normal ist). Ich kann mich allerdings nicht mehr einloggen. Erst nach dem Apache-Neustart geht es wieder. Dies lässt mich vermuten, dass es daran liegt, dass ich den Apachen als Worker und nicht als Prefork kompiliert habe. Kann das sein?

2. Stelle ich auth_type auf http, so habe ich diese Probleme nicht mehr. Aber es kommen laufend mb_regex errors. zum Beispiel in libraries/check_user_privileges.lib.php in Zeile 54
if ( (ereg($re0 . '%|_', $show_grants_dbname)
Das würde ja bedeuten, dass mbstring.func_overload an ist. Ist aber nicht der Fall. Das ganze konnte ich erst abstellen, als ich --disable-mbregex in die Konfiguration von PHP aufgenommen habe. Da diese Option aber noch nie Probleme gemacht hat, denke ich dass es nur eine Suboptimale Lösung ist. Hat jemand vielleicht eine Idee woran es liegen kann?

Ich hoffe, ich habe alles verständlich beschrieben. Ansonsten einfach fragen.

Und noch zur Info die Eckdaten von dem Server:
PHP 5.2.1
Apache 2.2.3 als Worker
phpMyAdmin - 2.9.2
MySQL 5.0.27

Danke im Voraus
flywalker

[flywalker]

hat niemand eine Idee?

[daemotron]

Wie hast Du PHP eingebunden? mpm_worker arbeitet mit Threads. Der PHP-Core selbst ist zwar threadsafe, aber nicht jedes PHP-Modul ist es auch... dann kann es zu Problemen kommen, wenn PHP als Apache-Modul läuft. Wenn Du ein PHP-Modul einsetzt, das nicht threadsafe ist, kommst Du wahrscheinlich nicht drum herum, PHP via FastCGI anzusprechen.

[flywalker]

Danke für die Antwort
ich habe PHP als Apache Modul kompiliert, das habe ich bis jetzt immer so gemacht. Allerdings mit Apache 1.3 oder 20 als Preforkgab es noch nie Probleme. Das ist das erste Mal das ich den Apachen als Worker kompiliert habe, und bis auf dieses Problem scheint ja alles gut zu laufen.
Da muss ich wohl entweder zurück zu Prefork wechseln oder PHP als FastCGI ansprechen.
Kann mir jemand vielleicht eine gute Anleitung / Übersicht empfehlen, wann man welche Möglichkeit wählen soll?
Danke!

[flywalker]

Hier noch Mal die Konfigurationen zur Info

Apache

Code: Select all

./configure --with-mpm=worker 
--enable-suexec 
--with-suexec-caller=wwwrun 
--enable-so 
--enable-rewrite 
--enable-headers 
--enable-ssl 
--enable-cgi 
--enable-authn-dbd 
--enable-layout=SuSE

PHP

Code: Select all

./configure 
--with-apxs2 
--with-mysql=/usr 
--with-mysqli=/usr/bin/mysql_config 
--with-gd 
--with-tidy=/usr/local 
--with-pear 
--with-zlib=/usr 
--with-zlib-dir=/usr 
--with-jpeg-dir=/usr 
--with-tiff-dir=/usr 
--with-png-dir=/usr/local 
--with-freetype-dir=/usr/local 
--with-xsl 
--with-imap=../imap-2006e 
--with-imap-ssl=/usr 
--with-gettext=/usr 
--without-sqlite 
--enable-ftp 
--enable-bcmath 
--enable-pcntl 
--enable-shmop 
--enable-mbstring 
--enable-zend-multibyte 
--with-curl 
--with-openssl=/usr

plus --disable-mbregex als Lösungsversuch für die phpMyAdmin regex Fehlermeldungen

flywalker

[daemotron]

Wie gesagt: PHP als Apache-Modul zusammen mit einem der threaded MPMs kann (muss aber nicht) zu Instabilitäten führen. Dem gehst Du aus dem Weg, indem Du entweder wieder zu mpm_prefork zurückwechselst oder eben PHP per mod_fcgi einbindest. So schließt Du zumindest das schon mal als Fehlerursache aus.

Links:
http://www.debianhowto.de/doku.php/de:h ... 2_php-fcgi
http://www.rootforum.org/forum/viewtopic.php?t=28561
http://www.rootforum.org/wiki/howto/ge ... ver/apache und http://www.rootforum.org/wiki/howto/ge ... r/php_fcgi
http://www.rootforum.org/forum/viewtopic.php?t=44319
http://www.google.de/search?hl=de&q=Apa ... fcgi&meta=

[flywalker]

Dank für die Links
ich werde mir das mal bei Gelegenheit durchlesen. Ich tendiere aber zu der altbewährte Lösung als Apache Modul. Deswegen werde ich es wohl wieder mit Prefork versuchen.

Danke!
flywalker

[flywalker]

hab apache als prefork installiert, trotzdem sind die Probleme immer noch da. Langsam bin ich verweifelt. Woran kann es denn noch liegen?
Kommischerweise läuft es auf meinem Testserver sogar als worker mit sonst gleicher konstellation völlig problemlos

[flywalker]

da ich keine Ideen mehr habe
denke ich an alles mögliche als Ursache für die Probleme
Die einzelnen Unterschiede zu dem Server, wo es ohne Probleme läuft sind:
- 64Bit Hardware (aber 32 bit SUSE-Linux)
- Software-Raid
könnte vielleich etwas davon als Ursache in Frage kommen?
HIIIILFE

[flywalker]

vielleicht hilft das:
nach einem Neustart von Apache läuft alles eine Zeitlang ohne Probleme. Dann kommen sie wieder

[daemotron]

32-Bit Linux ist eine gute Idee, wenn Du nicht mehr als 4GB RAM zu verteilen hast => kannst Du genauso wie Software-RAID eigentlich ausschließen. Wenn es nach einem Apache-Neustart eine Weile lang gut geht, klingt das fast, als würde Deinem Indianer die Puste ausgehen. Poste mal die /etc/apache2/servertuning.conf (oder so ähnlich) und schau mal in's error_log und access_log zu den fraglichen Zeitpunkten, ob sich nicht irgendwas findet. Ansonsten gerät das hier zur reinen Glaskugelguckerei...

[kase]

Du kannst dich nicht mehr einloggen bedeutet was genau (Fehlermeldung von phpmyadmin)?

Ansonsten mach mal folgendes:

Wenn das Problem wieder auftritt, lösche mal all deine Cookies (+danach Browser-Restart), ANSTATT den Apache zu restarten, dann können wir zumindest ausschließen, dass es ein Cookie Problem ist.

[flywalker]

naja manchmal gibt es gar keine fehlermeldung, nur das login formular wird angezeigt
manchmal, sagt er mir dass ich das Passwort falsch eingegeben hätte, was definitiv nicht stimmt
Cookies löschen hat nichts gebracht. Das hatte ich als erstes ausprobiert.
Vor allem würde es dem zweiten Problem "mb_ereg() [function.mb-ereg]: mbregex compile err: premature end of char-class" keine Abhilfe schaffen.
Ich glaube das hängt auch irgendwie zusammen. Denn beide Probleme verscwinden für eine kurze Zeit, wenn ich Apache neustarte.
Mir wurde ausserdem berichtet, dass bei ca 50% der Seitenaufrufe einer Seite in PHP, die auf meinem Server liegt, der Seitenlayout zerrschossen wird, weil strlen() falsche Werte liefert. Dies deutet auch auf mbstring_overload. Ist aber definitiv aus....