Hallo,

wir haben bei einem Kunden mit HELIOS Ub seit längerem das Problem, dass HELIOS Companion stehen bleibt.

Warum: Offensichtlich ist die Desktop Datei beschädigt.
Nach einem rebuild funktioniert der Companion wieder.

rebuild -s bringt keine Fehler - daher sollte die Desktop Datei in Ordnung sein.

Wir prüfen aber mit iddump das Volume und wenn es Probleme gibt kommt der Fehler -5000 bei iddump.


/usr/local/helios/bin/dt iddump /export/daten/vol01 > /tmp/dump.txt
dt iddump: DumpId: Error -5000 occured!: Error -5000 occured!

Im dump.txt letzte Zeile:

737988 737947 Bild.pdf

30 Sekunden später:

/usr/local/helios/bin/dt iddump /export/daten/vol01 > /tmp/dump1.txt

gibt es keine Fehler !!

Der nächste Eintrag in der Logdatei schaut ganz normal aus:

737988 737947 Bild.pdf
737989 737947 Datei.pdf

Wie sollen wir weiter vorgehen !
Warum bleibt der iddump hängen ?


danke

mfg

Hermann Schauhuber

Hallo,

Zitat

Wie sollen wir weiter vorgehen !

Vielleicht mal endlich die Ursachen für Desktop-Datenbank-Defekte eingrenzen? Steht das in einem Zusammenhang zu dem unter http://www.hilfdirselbst.ch/...i?post=245786#245786 Gepostetem?

Zitat

Warum bleibt der iddump hängen ?

Sind denn parallel noch Benutzer auf dem Volume angemeldet? Der Helios-Support weist jedenfalls immer beim Anforderung von iddumps darauf hin, daß kein User mehr das Volume in Benutzung haben darf.

Gruss,

Thomas

Nein, das steht nicht im Zusammenhang mit dem Xpress Call.

Tatsache ist, dass erst nach einem rebuild der Companion wieder funktioniert.

Da ein rebuild -s keine Fehler bringt, lesen wir das Volume mit iddump aus.
Der iddump bleibt auch dort stehen, wo Helios Companion ein Problem hat.

Das passiert auch am Wochenende, wo nachweislich niemand per Client arbeitet. Alle Scripte die laufen sind Helios konform mit den dt tools versehen.

mfg

Hermann Schauhuber

Hallo,

Zitat

Da ein rebuild -s keine Fehler bringt, lesen wir das Volume mit iddump aus.

Ich würde mal sicherstellen, daß definitiv kein Nutzer mehr mit dem Volume verbunden ist und dann erneut einen iddump probieren.

Wenn das schiefläuft, weiß ich zumindest auch nicht mehr weiter. Dann sollte man sich eben an den Helios-Support wenden (was ja als Fachhändler möglich sein sollte, oder)

BTW: Ein "rebuild -s" zeigt meines Wissens nicht an, wenn Dateileichen in der Desktop-Datenbank existieren (bspw. solche, die "schmutzig" auf das Volume gelangt sind, durch einen Zugriff seitens Mac-Client zu einem Eintrag in der Desktop Datenbank geführt haben und dann anschl. ebenso "schmutzig" wieder gelöscht wurden)

In einem iddump finden sich solche Leichen als Objekte ohne Parent-ID wieder. Sollte sowas auftreten, ist definitiv was faul bzw. wird "irgendwie" an der Desktop Datenbank vorbeigearbeitet.

Zitat

Das passiert auch am Wochenende, wo nachweislich niemand per Client arbeitet.

Spannend ist, ob "swho" eingeloggte Benutzer anzeigt oder nicht. Alles andere leider nur Spekulation.

Zitat

Alle Scripte die laufen sind Helios konform mit den dt tools versehen.

Ich komme bei Kunden auch immer wieder in Situationen, wo einem genau das versichert wird. Schaut man dann genauer nach, dann stimmt's halt meistens leider doch nicht. Der Fall, der obiges Problem mit den "Dateileichen" ohne Parent-ID erzeugt hat, resultierte aus irgendwelchen Zugriffen per NFS auf die Produktionsvolumes, wo zwar "eigentlich" auf dem anderen System die Verwendung der DT Utilities aktiviert war... aber de facto schlichtweg nicht funktionierte.

Gruss,

Thomas