---

Werte Mitstreiter,

ich bitte Euch bei meinen doch ungewöhnlichen Problem zu helfen.

Nach einem Reboot von Clients bzw. nach dem Einbinden neuer Clients in das laufende Netzwerk bleibt Catia V4 bzw. VPM beim Starten ohne Fehlermeldung stehen. Das Fenster wird aufgebaut, in der oberen Menu- Leiste steht "OPTION" und der Rest wird nur durch seine Hintergrundfarbe dargestellt. Die Lizenzen werden angezogen.
Das Problem ist Client-, aber nicht User abhaengig.

Wir haben ein neues homogenes IBM - Netzwerk mit einem Server der E- Serie und Clients mit 43P bzw. 44P Workstations. Auf allen läuft AIX4.3.
Die User- Verwaltung geschieht zentral über nfsmount der Verzeichnisse /home/user und /home/catadm vom Server.
Im Einsatz ist Catia V4.2.2 und Enovia mit VPM 1.3.

Im alten Netzwerk mit einer 42P als Server, ließ sich der Fehler mit dem Loeschen der
$HOME/.catia.appli beheben. Das Problem trat meistens nach einen "S006" bzw "S003" auf. Normalerweise wird die Datei beim Beenden geloescht, was in diesen Fällen nicht geschieht.

Im jetzigen Netzwerk laesst sich das Problem im Moment einzig mit  dem Durchstarten des gesamten Netzwerkes incl. Server für kurze Zeit beheben. Ein Reboot des Cleints ist nicht ausreichend.
Die ".catia.appli" wird erstellt im $HOME , aber mit dem Inhalt 0.

Im Aufbau des Netzes trat die gleiche Problematik auf. Damals waren aber die maximal zulaessigen "nfsd" und "biod"- Prozesse auf dem Server zu gering deklariert. Standardeinstellungen sind
nfsd = 8; biod = 6.
Diese sind derzeit jeweils auf den Wert 4999 eingestellt.

Hat jemand ähnliche Probleme oder kann mir weiterhelfen bzw. hat Anregungen?
Ich bin für jede Nachricht dankbar.

------------------
-------------------------
Gruss
Matthias Werner

IP

---

Noch einige Ergaenzungen:

Wie im Beitrag "CATIA V4 mit Linux-Server" vom 11.06.02 beschrieben, treten die gleichen Ungereimtheiten auf.

Beim Starten wird ein defunct- Prozess erzeugt. Dieser laesst sich nicht mit "kill -9 PPID" beenden. Der Prozess mit der PID  gleich der PPID des "defunct" wird zu einem Prozess mit der Beschreibung []. Dessen PPID wird auf 1 und die Zeit auf 01.Jan (wahrscheinlich erstes erreichbares BIOS- Startdatum) gesetzt.
[PID- Process ID; PPID- Parent process ID]

Auch die in diesem Zusammenhang angesprochen lock und stat- Daemons sind von Interesse. Die Anzahl der moeglichen Prozesse fuer den lockd wurde heute daraufhin von 40 auf 4096 erhoeht und das gesamte Netz durchgestartet. Fuer den stat- Daemon wurden keine Einstellmoeglichkeiten gefunden.
Sind fuer den "statd" ebenfalls weitere Einstellungen moeglich?
Welche sind die genauen Aufgaben der beiden Daemons?

Resumee:
Wie aus dem anderen Beitrag hervorgeht, tritt der Fehler Plattformuebergreifen auf (LINUX/AIX- SERVER). Die Frage ist, ob es an den Clients liegt? Vieles spricht dafür.

Wenn sich Veraenderungen ergeben, werde ich diese hier veroeffentlichen.

Wir freuen uns aber dennoch über jede Anregung und Hilfe.

In diesem Sinne, bis bald

------------------
-------------------------
Gruss
Matthias Werner

IP

---

Hallo Matthias,

wir haben eine reine HP-Umgebung (Server+Clients) und hatten ein ähnlich klingendes Problem ca. ein Jahr lang zwischen 1998 und 1999. VPM hatten wir damals noch nicht im Einsatz, CATIA blieb auf einigen WS nach drücken von ColdStart hängen. Reboot des Clients half nicht. Das Problem wurde über ein Jahr bei IBM/DS und HP verfolgt, eskaliert, ... Raus kam dabei nichts. Man vermutete ein NFS-Problem - es trat allerdings nur mit CATIA und mit keiner anderen Anwendung auf. Verschwunden ist das Pbm möglicherweise mit einem Generationswechsel bei den Clients. Genau wissen wir das aber nicht.

Wir haben damals folgende PbmBeschreibung festgehalten:

CATIA bleibt beim COLD START hängen. Prozesse options+CAT* lassen sich nicht killen. Beim Killen von dtsession bleiben Prozesse als Söhne des root-Prozess übrig. Empfehlung von WHo: 'shutdown -yh 0' und Maschine mind. 30 Minuten ausschalten. 30 Minuten ausschalten hat geholfen !

Viel Spaß noch

Dirk

IP

---

Halll Leute

Wir kennen das Problem auch. Vor einigen Jahren hatten wir das Problem in unserer Zentrale in einem Netz aus IBM und SGI Rechner( betraf aber immer nur die IBMs, glaub ich). Damals war das Problem Userabhänig. Nach dem das Homedirectory neuangelegt wurde lief wieder alles. Die Homes waren über NFS gemounted. Nachdem wir unsere Konfiguration von Server und Clients geändert haben, ist das Problem nicht mehr aufgetaucht.
Vor einiger Zeit tauchte nun das Problem in einer Niederlassung wieder auf. Die Konfiguration ist die änlich wie in der Zentrale. Wir verwenden NIS und automounts. Meistens tritt das Problem auf wenn der Server rebooted wurde oder er nach den Clients up ist. Dann hilft das NFS auf dem Server neuzustarten und das Verzeichnis /etc/sm.bak zulöschen.
100 prozentig sind wir aber auch nie hinter das Problem gekommen.

Gruß

Frank

IP

---

Hallo,

wir haben den bos.nfs.client von Version 4.3.3.75 auf Version 4.3.3.84 gehoben. Seit dem hatten wir keine Problem.

------------------
Zoltan Pleth

IP

---

Hallo,
Hatten auch gerade das Problem. Nachdem ich die richtige Antwort (die Lösung die bei uns richtig war) da nicht gefunden hatte möchte ich die einfach anfügen (falls ich wieder mal vergesse das es dokumentiert ist).

Also die Ursache war das der (NFS) Server den Hostnamen des Clients nicht kannte.
Ist passiert weil wir den Hostnamen geändert hatten und der Slave Server im NIS noch nichts mitbekam (hab das mit ypxfr behoben).

mfg Erich

IP

---

was nog zu bedenken ist welches netzwerk wird genutzt token-ring oder ethernet?

IP