Postgres Connection

Hallo Leute,

wir haben hier einen Debian 4.0 Server mit einer Postgres 7 Installation. Ein externer Programmierer hat ein Frontend geschrieben mit dem man auf die jeweiligen Tabellen zugreifen kann (Daten auslesen einpflegen usw.). Bisher lief auch alles ohne Probleme aber seit einiger Zeit ist es so das wenn das Frontend geschlossen wird dieses “hängt” und es mehrere Sekunden dauert bis es geschlossen wird. Dieses Phänomen tritt aber wiederum nur bei Rechnern auf die innerhalb der Windows 2003 Domäne sind, Rechner außerhalb der Domäne haben dieses Problem nicht. Wir haben das mit dem selben User in und außerhalb der Domäne geprüft. Der Debian Server liegt im selben IP Netz und ist über Samba mit der Domäne verbunden (Browserliste Netbios). Die Namensauflösung DNS und NETBIOS funktionieren ebenso einwandfrei. Wir haben jetzt noch einmal den Debian Server und die Datenbank geupdatet aber alles ohne sichtbaren Erfolg. Alle Rechner verbinden sich über einen ODBC Treiber und verwenden auch die selbe Version des Frontends. Woran könnte es noch liegen das dieses Problem auftritt?

Gruß

Schwierig zu sagen. Das Problem sollte mit der Fragestellung “Was wurde kurz vor dem ersten Auftreten des Problems an den beteiligten Komponenten verändert?” untersucht werden. Offensichtlich spielt die Verbindung über/zu der Windows 2003 Domäne eine erhebliche Rolle. Einfacher ist es, wenn man weiß, was das Frontend bei der Beendigung des Programmes an Funktionen aufruft. Vielleicht habt ihr ja der Sourcecode oder könnt der Programmierer fragen.




mfg

fristo

Hi fristo,

wir haben mit Netmon, Filemon und Regmon das verhalten des Frontends geprüft. Im Netmon sehen wir einen stetigen Netzwerkverkehr zwischen Debian Server und dem Client bis auf beenden geklickt wurde dann stoppt alles und nach 20s gehts weiter und das Programm schliesst sich… ebenso die File und Registry Operationen. Auf den nicht domain Rechnern gehts in einem Rutsch. Die monatlichen Windows Updates kommen wohl auch nicht in Frage da alle Clients automatisch geupdatet werden und auf dem aktuellsten Stand sind. Das ganze scheint sich auch weiter auszudehnen da sich jetzt bei einigen Benutzern mittlerweile der Start ebenso lang hinzieht. Den Entwickler haben wir leider noch nicht erreicht…

Das, also die 20 Sekunden, klingt extrem nach einem Timeout für eine Namensauflösung. Vielleicht ist der erste DNS-Server tot und es wird auf dessen Timeout gewartet. Dann wird der zweite gefragt, der antwortet und alles wird gut. Das typische Timeout bei DNS liegt bei gefühlten 20 Sekunden…

Andreas

Hallo dstr123,

Gut getestet. Da waren Profis am Werk. Die 20s können ein Hinweis darauf sein, dass das Betriebssystem letztendlich den Prozess des Frontends gekillt hat. Es gibt da eine Konstante in der Registry. Man hat das auch schon meistens selbst erlebt, wenn Windows heruntergefahren wird. Es dauert dann länger als normal. Das Betriebssystem fordert die noch offenen Programme auf sich selbst zu beenden. Erfolgt das nicht in 20s, killt das Betriebssystem den Prozess des Programms um letztendlich den Shutdown zu beenden.

Einer der letzten Befehle, die ein solches Frontend bei Beendigung des Programms ausführt, heißt “close connection”, also die Verbindung zum Server beenden. Liege ich mit meiner Vermutung richtig, dass hier die Ursache ist, und Windows killt den Prozess den Frontends, kann man das leicht feststellen. Da die Verbindung zur Datenbank nicht ordentlich beendet wurde, müssen auf dem Debian 4.0 Server Zombie-Prozesse namens postmaster vorhanden sein. Dieses kann man mit “ps -C postmaster” herausfinden.

Wichtig: Beim Starten der PostgreSQL Datenbank werden 4 Prozesse “postmaster” gestartet. Pro Verbindung zu einem Client kommt 1 Prozess “postmaster” dazu.

Trifft das obige geschriebene zu, würde ein Hardware-Problem im Netzwerk-Pfad von den Clients zum Debian 4.0 Server existieren. Da auf den nicht domain Rechnern alles funktioniert kann man das Frontend und auch die PostgreSQL-Datenbank als Ursache ausschließen, ebenso gilt das für den Debian 4.0 Server sowie die Clientrechner.

Wie sollte man nun weiter vorgehen? Man sollte zunächst mit dem Befehl “tracert” den Netzwerkpfad von den (domain / nicht domain) Rechner zum zum Debian 4.0 Server untersuchen und nach dem Ausschlußverfahren arbeiten. Anhand der angegeben Laufzeiten kann man auch Aussagen machen. Hilfreich könnte hier hierbei sein, dass die Probleme jetzt auch beim Starten des Frontend auftreten. Zu dem Zeitpunkt wird die Verbindung zur Datenbank aufgebaut! Werden keine Ungereimtheiten feststellen, kann man die Netzwerkkomponenten (Hub, Ports, etc) ausschließen. Allerding es gibt machmal auch Geräte, die einen langsamen Tod sterben, d. h. sie funktioniern mal, dann wieder nicht usw… Nach diesen Test bleiben dann nur noch alle Computer übrig, die nicht in den Test einbezogen wurden, wie z. B. der Rechner “Windows 2003 Domäne” etc.




mfg

fristo

Vorsicht: die postMASTER-Prozesse gehören zum Server selbst, Clients starten postgres: - Prozesse. Zumindest sieht man sie unter diesem Namen bei ps -ax. Sie werden allerdings initial als postmaster gestartet, das ist korrekt.

Trifft das obige geschriebene zu, würde ein Hardware-Problem im Netzwerk-Pfad von den Clients zum Debian 4.0 Server existieren.

Ich denke, das ist eher unwahrscheinlich. Wenn ich den Fragesteller korrekt verstanden habe, tritt das nur auf, wenn der Client in der Domäne ist. Meldet man sich auf dem Client lokal an, klappt alles. Ich bezweifle erheblich, ob sich die Rechner- oder Netzwerkhardware danach richtet, ob ich am Rechner lokal oder an einer Domäne angemeldet bin.

Da auf den nicht domain Rechnern alles funktioniert kann man das Frontend und auch die PostgreSQL-Datenbank als Ursache ausschließen, ebenso gilt das für den Debian 4.0 Server sowie die Clientrechner.

Korrekt.


Hilfreich könnte hier hierbei sein, dass die Probleme jetzt auch beim Starten des Frontend auftreten. Zu dem Zeitpunkt wird die Verbindung zur Datenbank aufgebaut!

Korrekt. Aber da werden wohl kaum Prozesse beendet, auf deren Beendigung das OS warten muß. Oder?


Werden keine Ungereimtheiten feststellen, kann man die Netzwerkkomponenten (Hub, Ports, etc) ausschließen. Allerding es gibt machmal auch Geräte, die einen langsamen Tod sterben, d. h. sie funktioniern mal, dann wieder nicht usw…

Das Wort zum Sonntag? Okay: Amen!

Sorry, wenn das eben etwas bissig klang. Aber ich glaube, das führt in die flasche Richtung.
Ich vermute nach wie vor ein DNS-Problem. Entweder haben die Clients beim Domänen-Login einen toten DNS
eingetragen oder melden sich mit einem dann (und nur dann), den der Server nicht revers auflösen kann.

Vielleicht, aber da begeb ich mich jetzt auf Glatteis, kommen mit der Domänenanmeldung auch irgendwelche Firewall-Policies zum Einsatz, auf die die Applikation so reagiert. Vielleicht testet sie dann, und nur dann, auf die Verfügbarkeit eines z.B. Webservers, bevor sie weiterarbeitet. XP macht bei Netzwerklaufwerken sowas, Stichwort WebDAV. Wenn da der Server auf Port 80 ein DROP macht, hat man IIRC auf das 20-Strafsekunden-Problem.

Von daher: es reicht nicht zu sagen: dann ist kein Netzwerktraffic. Interessant wäre: was geht unmittelbar vor den 20 Sekunden über die Leitung. Und ich bin mir sehr sicher: das ist ein TCP/IP-Packet mit gesetzten SYN-Flag und ohne ACK. Und wenn wir nun noch IP und Ports wissen würden, wäre die Lösung sehr wahrscheinlich klar. Und all das ohne Bullshit wie ‘langsam sterbende Hardware’.



Andreas

Nutzt die Applikation Netzwerk-Laufwerke (zum Daten ein- und auslesen)? Falls ja: werden diese beim Domänen-Login via Login-Script zugewiesen? Handelt es sich um XP-Clients? Ist auf dem Debian-Server auch das SAMBA drauf UND ist dort eine ‘Firewall’, die als Policy DROP verwendet? Und bietet dieser Server KEINE HTTP-Dienste an?

Falls Du diese Fragen mit ja beantworten kannst, sehe ich Licht am Ende des Tunnels. Siehe auch meine anderen Beiträge heute.

Andreas

Hallo Leute,

wir haben das Problem gelöst! :smiley: Ich trau mich aber fast nicht zu sagen woran es gelegen hat. :rolleyes: Vor einiger Zeit wurde auf allen Clients der ISA Server Firewall Client deployed. Jetzt werden sicherlich alle denken na is ja klar der blockt die Ports oder den Server aber es ist so das der Firewall Client prüft an wen das Paket gesendet werden soll. Befindet sich das Ziel im lokal definierten Netz wird das Paket auch direkt an den Server ohne Filter ohne Firewall weiter geleitet. (Stichwort LAT) Der ISA Server lässt ebenso intern alles passieren! Nun haben wir nochmals Netmon, Regmon und Filemon angeworfen und gesehen das unser Frontend bei einem winsock Aufruf beim Beenden stehen bleibt. Vorher läuft der Netzwerkverkehr normal und ohne Probleme - Änderungen im Frontend werden in die Datenbank übertragen usw. Wir hatten auch bei unserem ersten Test den Firewall Client deaktiviert. ABER das reicht nicht wie wir jetzt heraus gefunden haben. Der Firewall Client muss deinstalliert werden damit das Frontend wieder normal funktioniert. Der FC kapselt die Winsock und das scheint unser FE nicht zu mögen. Außerdem generiert das Frontend scheinbar Cache files oder so etwas, denn nachdem der FC nun deinstalliert ist sehen wir nach dem Aufruf des FE’s mehrere temp Dateien die beim schließen wieder verschwinden. Wie das mit dem FC zusammen hängen kann ist uns noch nicht ganz klar…
Trotzdem vielen Dank an euch alle für eure Hinweise, denn sie haben uns geholfen alles noch einmal zu überprüfen und die Lösung zu finden.

Gruß

DSTR

Danke für die Rückinfo. Tja, ein schönes Beispiel, wie durch vermeintliche Sicherheitssoftware mehr Schaden als Nutzen entsteht…

Andreas

Ich frage mich, warum bei jeder komischen Tischfeuerwand unter Windows immer die komplette Software deinstalliert werden muss, bis das “Firewall ist ausgeschaltet” auch wirklich den Netzwerktraffic nicht mehr beeinflusst.

Jepp, zumal man auch nix extra braucht. Ab 2000 kann man RUS-CERT - Microsoft IPSec als Paketfilter einsetzen und/oder NT-Dienste sicher konfigurieren und abschalten (Windows 2000/XP) - www.ntsvcfg.de verwenden, was weder die Codebasis von Windows verändert / erhöht noch negative Nebenwirkungen hat. Mehr als das können Tischfeuerwände ja eh nicht…

Aber wir schweifen vom Topic ab.


Andreas

Hallo ads,

schlicht und einfach, notwendigerweise wurden bei der Installation einige DLL’s ausgetauscht (Kapselung von Winsock). Das Problem ist aber ein BUG in der Applikation selbst. Wenn der Firewall inaktiv ist, bedeutet das ja nicht, dass die Applikation nichts mehr zu tun hat. Vielmehr müssen die Funktionsaufrufe an Funktion mit den ursprünglichen Eigenschaften weitergeleitet werden. Und wer schon mal selbst DLL’s aufgebohrt hat, weiß, der Teufel steckt im Detail.

Eigentlich schade, dass die Software nicht unter UNIX installiert war. Zu gerne hätte ich von Dir erfahren, wie man unter UNIX ohne die vollständige De-Installation der Software ausgekommen wäre.





mfg

fristo

Das versteh ich jetzt nicht, was meinst Du?

Andreas

Unter Unix tauscht du auch nur ganz selten komplette Libraries aus sondern legst einfach nur einen Symlink um. Dabei ist ein Wechseln zurück zur alten Applikation problemlos möglich.

Wir haben aber nicht von Unix gesprochen sondern davon, das jede zugekaufte/installierte Tischfeuerwand unter Windows bisher das gleiche Problem gezeigt hat: man sagt der Firewall “du bist jetzt deaktiviert”, aber sie filtert trotzdem noch. Erst wenn man die Software komplett deinstalliert, funktioniert auf einmal der Internetzugang wieder so, wie gewünscht.

Hat jetzt also jede Firewall Software das gleiche Problem? Oder habe ich ein grundsätzlich falsches Verständnis von “deaktiviert”? Bin ich Schuld am schlechten Konzept der DLLs unter Windows?

Fragen über Fragen …