PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : apache2+php+oracle user-problem?



frqmaster
05.03.05, 00:42
Hallo liebe Linux-Community,

Dies ist mein allererstes Posting in einem Linux-Forum. Überhaupt habe ich bisher noch nie mit Linux gearbeitet. Daher bitte ich schon mal um Entschuldigung, wenn meine Formulierungen vielleicht manchmal nicht ganz korrekt sind. Linux ist zwar absolutes Neuland für micht, macht aber auf den ersten Blick als Server-BS schon Spaß....

So nun zu meinem Problem:

Ich habe ein Suse 9.2er Linux mit einem Apache2-Webserver. Auf dem Apache läuft ein PHP 4.3.x.x-Modul. Der Webserver läuft unter dem "root"-User.
Daneben läuft noch eine Oracle 9.2.x.x-Datenbank unter dem "oracle"-User.
Ich habe PHP unter anderem mit --with-oracle=$ORACLE_HOME kompiliert, damit ich aus PHP auch auf die Oracle-DB zugreifen kann.

Ich bekomme php-seitig keine Verbindung zur Oracle-DB hergestellt. Das Script wirft auch keine PHP-Fehlermeldung. Dafür erhalte ich in der /var/log/apache2/errors_log dubiose "Segmentation fault (11)"-Fehler ...

Woran könnte das liegen?
Meine laienhaften Vermutungen (eines Windows-Users) wären:
1) Webserver (unter root) kann nicht auf DB-Client zugreifen, da dieser für "oracle"-User installiert wurde ?
2) PHP oder Apache nicht korrekt kompiliert ?

Ich hoffe, ihr könnt mir vielleicht helfen. Vielleicht hat ja schon mal jemand eine solche Kombination eingesetzt.

Grüße,
frqmaster

bla!zilla
05.03.05, 08:04
Kannst du vielleicht mal den kompletten Eintrag im error_log posten? Raucht da vielleicht ein Childprocess vom Apache ab?

frqmaster
07.03.05, 13:41
Hi,

Per Shell über sqlplus (root-User) bekomme ich eine Connection aufgebaut.
Über PHP/Apache nach wie vor immer noch nicht.
Aber mittlerweile bekomme ich immerhin schon n PHP-Error:

Warning: Oracle: Connection Failed:
Error while trying to retrieve text for error ORA-01019
in /srv/ftp/ordner/toolz/test.php on line 15


Die Einträge im error_log sehen wie folgt aus:

[Mon Mar 07 13:32:47 2005] [notice] child pid 25623 exit signal Segmentation fault (11)
[Mon Mar 07 13:32:48 2005] [notice] child pid 19089 exit signal Segmentation fault (11)

Irgendeine Idee?
Mir sagt so eine Fehlermeldung absolut gar nichts, außer das vielleicht ein Apache-Child-Prozess abgeraucht ist. Aber wieso?

Ich weiß nicht, ob's was hilft, aber unterm Apache laufen folgende Module:

core prefork http_core mod_so mod_access mod_actions
mod_alias mod_auth mod_auth_dbm mod_autoindex mod_cgi
mod_dir mod_env mod_expires mod_include mod_log_config
mod_mime mod_negotiation mod_proxy proxy_http mod_rewrite
mod_setenvif mod_ssl mod_suexec mod_userdir sapi_apache2

PHP wurde folgendermaßen konfiguriert:

'./configure' '--prefix=/usr' '--datadir=/usr/share/php'
'--mandir=/usr/share/man' '--bindir=/usr/bin' '--libdir=/usr/share'
'--includedir=/usr/include' '--sysconfdir=/etc' '--with-_lib=lib64'
'--with-config-file-path=/etc' '--with-exec-dir=/usr/lib64/php/bin'
'--disable-debug' '--enable-inline-optimization' '--enable-memory-limit'
'--enable-magic-quotes' '--enable-safe-mode' '--enable-sigchild'
'--disable-ctype' '--enable-session' '--enable-cli' '--with-pear'
'--with-oracle=/opt/oracle/920' '--with-oci8=/opt/oracle/920'
'--with-gd' '--with-jpeg-dir=/usr/lib64/' '--with-png-dir=/usr/lib64/'
'--with-zlib' '--with-apxs2=/usr/sbin/apxs2-prefork' 'x86_64-suse-linux'

frqmaster

frqmaster
07.03.05, 19:11
OK es geht voran ...

ABER: Das äußerst merkwürdige daran ist:

Ich bekomme mit den PHP-oracle-Funktionen keine sichtbare Verbindung zum Apachen. Im Browser sieht's so aus, als wenn die Seite gar nicht existieren würde. Dafür stehen lustige [Mon Mar 07 13:32:47 2005] [notice] child pid 25623 exit signal Segmentation fault (11)-Einträge im error_log. :mad: :mad:

Nun, wenn ich allerdings die Oracle-Verbindung per OCI8-Funktionen herstelle, klappt dies ohne weiteres und ohne abrauchen von Child-Prozessen!!! :eek: :eek:

Nun frage ich mich: "Ist das ein allgemeiner Bug in der Kobination Suse9.2 + Apache2 + PHP4.3 ???"
Oder hab ich was falsch gemacht? Weil das kann doch eigentlich nicht sein, dass die Verbindung auf die eine Art klappt - wogegen auf die andere Art ganze Prozess-Horden abrauchen !?

Ich hab diesbezüglich bereits ausführlichst gegoogelt und gelesen. Das Prob scheinen auch einige wenige andere User zu haben, aber eine Lösung habe ich noch nicht ausmachen können...

Hat denn niemand von euch kompetenten Leuten eine Idee?

frqmaster

rkauskh
07.03.05, 19:23
Hi

Saublöde Frage, aber gibt's in Oracle auch den User root (warum läuft dein Apache eigentlich als root und nicht wie bei SuSe üblich wwwrun???) und hat er Zugriffsrechte auf die DB? Ist Oracle hier eine Ausnahme? Denn alle anderen mir bekannten DB's verweigern sonst den Zugriff.

MfG
rk

frqmaster
07.03.05, 22:02
In der Oracle-DB existiert natürlich kein root-User - der hat ja auch nichts mit demr RDBMS an sich zu tun.

Dass der Apache nun als root läuft, ist nicht meine Idee gewesen. Ich bin nur "Zweitnutzer" - ansonsten Dient der Server vor allem ApplicationServer (Tomcat) für Java-Anwendungen.

Aber zurück zu meinem Problem:
Ich bekomme unterm root (also der selbe User wie auch für den Apache) per Shell ohne Probleme Zugriff auf die Datenbank.
Ich bekomme auch über PHP/Apache per OCI8-PHP-Funktionen [ocilogon(), etc.] Zugriff auf die Datenbank.
"Lediglich" bei der Benutzung der oracle-PHP-Funktionen [ora_logon(), etc.] bekomme ich "segmentation faults"!

Daher meine Frage: Kann das ein Linux / Apache / Kompilierungsfehler sein und wie kann man so was lösen? Haben das Problem noch mehrere?
Bzw. wie ist die grundsätzliche Fehlersuche unter Linux, wie kann ich die Ursache für sowas feststellen?

Grüße,
frqmaster

rkauskh
07.03.05, 22:42
Hi

Sorry für die Frage, aber besser mal was blödes gefragt als das was ausgelassen wird oder?
Hab nochmal gesucht und eigentlich als mögliche Lösungen nur entweder den Test des neuesten PHP-Snapshots zu versuchen oder wieder auf PHP4.3.9 zurückzukehren.
Ein anderer Vorschlag war die max Connections des Apache um eine Nullstelle zu erhöhen. :confused:

MfG
rk

frqmaster
08.03.05, 00:29
Ja, danke. Ich denke ich werde mal eine andere PHP-Version testen - in der Hoffnung, dass sich damit das Problem von selbst löst.
Eventuell auch gleich auf PHP5 umswitchen. Hoffentlich macht das der Hauptadmin mit. :-)

Ich werde auch mal versuchen an den Parametern in der httpd.conf zu drehen und mein Ergebnis im Laufe des Tages mal posten.

Jetzt mal ne blöde Frage von mir (Bin ja wie gesagt Linux-Frischling):
Muss ich den Apache neu kompilieren wenn ich auf ne andere PHP4 oder gar PHP5-Version switche?
Weil ich den Apache möglichst mit Samthandschuhen möchte / sollte. Da sind einfach zu viele Dinge konfiguriert, damit Tomcat/Java die richtigen Requests bekommt.

frqmaster

frqmaster
08.03.05, 20:06
Oh ... oh ... oh ...

Jetzt kommt mal eine richtig blöde Frage von mir:
Auf meinem System war PHP 4.3.4 als RPM-Paket installiert.
Nun hatte ich mir ja naiverweise eine aktuellere PHP-Source (4.3.10) runtergeladen und diese selbst kompiliert (configure, make, make install).

Ähm ... die alte PHP-Version ist ja immernoch als RPM installiert. Aber die neue Version wird vom Apache benutzt.

Rühren eventuell meine heftigen Probleme daher??

Was sollte ich jetzt am besten tun? Bekomme ich meine selbst-kompilierte PHP-Version wieder "deinstalliert", sodass ich wieder auf dem alten Stand bin?

Was mache ich aber, wenn ich keine PHP-Module als RPM's bekomme - dann muss ich eh wieder kompilieren und habe wieder das selbe Problem...
Ich seh im Moment nicht mehr durch.

Bitte um Hilfe!

rkauskh
08.03.05, 21:05
Hi

Ich dachte du nutzt schon die 5er PHP-Version. Jetzt bin ich aber richtig :confused:
Mein 1. Vorschlag:
Das alte RPM deinstallieren.
Im Sourcepfad von PHP4.3.10 nachsehen ob ein install.log oder so ähnlich vorhanden ist. Dort steht drin was er wohin geschrieben hat. An dieser Stelle sehe ich 2 Möglichkeiten. Entweder mal versuchen ob als root ein "./make uninstall" in einer Konsole im Sourceverzeichnis funktioniert oder die Dateien von Hand löschen.
Danach PHP5 (letzter stabiler Snapshot) compilieren und Apaches httpd.conf in der Sektion loadmodules anpassen. Apache neu starten. Lies dazu aber bitte unbedingt noch ein HowTo, ob meine Reihenfolge stimmt.

Mein 2. Vorschlag
Die alten PHP's drauf lassen und PHP in ein eigenes Verzeichnis kompilieren
(--prefix=/usr/local/PHP5 usw.)
Danach noch die httpd.conf anpassen und darauf achten das die PHP4 und 5 Module von Apache nicht gleichzeitig geladen werden. Das geht definitiv in die Hose. Auch hier vorher nochmal prüfen das ich nix vergessen hab. Mach das auch nicht jeden Tag.

Ich hab bei Oracle noch was zum Thema gefunden glaub ich:


Managing Connections

Optimizing database connections in a frequently used script can improve performance and prevent resource problems. Some tips are:

*

Avoid multiple connections to Oracle in a single script.
*

If you have to make multiple connections use different tnsnames.ora aliases, even when you want to connect to the same Oracle instance with a different user. This will avoid PHP context conflicts since each connection will use a distinct TCP link to the database.
*

Using the "persistent" OCIPLogon() call minimizes the number of physical connection requests to the database. It has some limitations. If the DBA terminates the session with ALTER SYSTEM KILL SESSION or worse, terminates the Oracle shadow process with an operating system kill command, OCIPLogon() may succeed but subsequent OCI8 calls may still fail. This can be timing dependent. When reusing a persistent connection always check its validity at the start of the script with an explicit query. If you receive an Oracle error then the connection is no longer valid and you may need to logoff and login again. Some developers give the user a message asking them to retry later and call PHP's apache_child_terminate() to clean up the session.
*

Use Oracle Database Resource Manager (which replaces User Profiles) to limit the resources used by any one connection.
*

Use Oracle Net configuration parameters such as SQLNET.EXPIRE_TIME to free up unused database resources.
*

Refresh the Apache processes after they have managed a certain number of requests, depending on site load. An Apache "graceful restart" nightly will clean up connections.

Das würde wieder für die Theorie mit mehr gleichzeitig zulässigen Connections aus meinem letzten Beitrag sprechen. Versuch macht kluch. :D