Moin allerseits!

Heute hab' ich mal was richtig seltsames und weiß im Augenblick wirklich nicht mehr weiter. Die Ausgangslage: eine VM mit Webserver (openSUSE, apache) liefert im Intranet einige Skripte zum DB-Reporting aus. Einige dieser Skripte greifen auf eine Oracle-DB auf einem anderen Host im Intranet zu. Seit heute morgen funktioniert dieser Zugriff nicht mehr.

Als erstes habe ich versucht, das Problem bei mir zu reproduzieren. Eine Kopie der Produktions-VM läuft hier lokal für die Entwicklung und kommt via VPN auch ins Intranet. Von meiner VM aus funktioniert der Oracle-Zugriff so wie immer.

Ich habe dann ein kleines Skript geschrieben, um die Verbindung auf beiden VMs zu testen und dabei DBI->trace(2) gesetzt. Auf meiner VM läuft das problemlos durch, auf der Produktions-VM erhalte ich den folgenden Trace:

    DBI 1.608-ithread default trace level set to 0x0/2 (pid 6903) at conntest.pl line 10

    -> DBI->connect(dbi:Oracle:host=myorahost;sid=mysid, myuser, ****, HASH(0x8167c28))

    -> DBI->install_driver(Oracle) for linux perl=5.008008 pid=6903 ruid=0 euid=0

       install_driver: DBD::Oracle version 1.23 loaded from /usr/lib/perl5/site_perl/5.8.8/i586-linux-thread-multi/DBD/Oracle.pm

    -> STORE in DBD::_::common for DBD::Oracle::dr (DBI::dr=HASH(0x820ebe0)~0x820ec1c 'ShowErrorStatement' 1) thr#8167008

    <- STORE= 1 at Oracle.pm line 70

    <- install_driver= DBI::dr=HASH(0x820ebe0)

    -> connect for DBD::Oracle::dr (DBI::dr=HASH(0x820ebe0)~0x820ec1c 'host=myorahost;sid=mysid' 'myuser' **** HASH(0x8219648)) thr#8167008

Danach: nichts mehr. Das Skript wartet auf den Connect und wurde nach mehreren Minuten von mir gekillt.

Also habe ich während des Verbindungsversuchs mal auf beiden VMs ein tcpdump mitlaufen lassen und mir anschließend in Wireshark genauer angesehen. Dabei stellte sich heraus, daß meine eigene VM einen Dialog mit dem Oracle-Host führt, so wie man es erwartet (ohne jetzt die Details des Dialogs zu verstehen, aber die beiden reden jedenfalls an einer Stelle TNS miteinander und das Ergebnis sieht wie immer aus...) Im tcpdump-Output der Produktions-VM hingegen taucht der Oracle-Host nur mit einem einzigen Paket auf (ein NetBIOS-Broadcast), d.h. perl verschickt schlichtweg keinerlei Pakete, wie es scheint.

Niemand hat diese VM seit gestern angefasst, gestern lief es problemlos, heute nicht. PHP-Skripte sind genauso betroffen, offenbar liegt die Ursache im System und nicht in der Anwendung. Die Netzwerkanbindung der Produktions-VM ist ja aber offenkundig in Ordnung, denn ich kann mich darauf anmelden und ich kriege von dort aus auch ein stabiles ping zum Oracle-Host, kein Problem soweit. In /var/log/messages sieht man eine Menge Geschnatter vom nmbd, aber sonst nichts auffälliges. Die Kiste hat heute eine Uptime von 50 Tagen, kann also auch nicht an irgendeinem Skript liegen, das man eigentlich schon längst mal ordentlich im Init-Ordner einbinden wollte o.ä.

Hat jemand sowas schonmal gesehen? Ich bin wirklich verwirrt...

Nach einem Neustart der VM trat das Problem dann nicht mehr auf.

Aber ob mich das nun beruhigen soll? Eine Ursache zu finden hätte ich wohl befriedigender gefunden...