Das Notes Forum
Domino 9 und frühere Versionen => ND8: Administration & Userprobleme => Thema gestartet von: koehlerbv am 08.12.11 - 14:58:12
-
Ich möchte auch mal wieder eine Frage haben, obwohl die Auflösung wohl so einfach wird, dass ich mich hinterher blind nennen werde:
- Ein scheduled agent, der handbetrieben tut was er soll.
- Dieser Agent startet auf einem Server der Organsation A scheduled, wie er soll: Alles in Ordnung, Ergebnis passt
- Gleicher Agent in anderer DB (identische Schablone) auf einem Server der Organisation B tut *nicht*.
- Laut Agent-Protokoll ist der Agent gelaufen, hat sich aber in der gleichen Sekunde wieder beendet.
- Im Server Log findet sich Null Verweis auf diesen Agent (obwohl Agent-Starts geloggt werden)
- Sicherheitsstufe ist schon 3 (obwohl unnötig)
- Eine der ersten Amtshandlungen des Agents ist die Anlage eines Protokoll-Dokuments. Auch das bleibt aus.
- Signer ist eine "technische ID" - wie bei allen anderen Agents auf dem Server.
- Signer steht wie der Server mit allen Rechten in der ACL.
- Die "technische ID" kann den Agent manuell ausführen.
Was könnte ich noch übersehen haben? Danke im Voraus für jeden Hinweis!
Bernhard
-
Auch wenn du das höchstwahrscheinlich geprüft hast:
steht denn unter Zeitplan -> auführen auf der richtige Server drin?
-
Ja. Leider ... Das Agent-Protokoll würde ja sonst auch leer bleiben, weil der "falsche" Server sich nicht bemüssigen würde, das Teil zu starten.
Aber danke für Deine Gedanken! Irgend so etwas simples muss es ja sein.
Bernhard
-
Im Agenten ist aber kein Run on behalf eingestellt ?
-
Leider nein. Aber auch das würde ja zumindest zu einer Fehlermeldung im Log führen (wenn dort Schütze Arsch im letzten Glied eingetragen wäre).
Danke, Ingo.
Bernhard
-
Was ist denn mit serverseitigen Einstellungen? Man kann doch z.B. auch die Laufzeit von Agenten begrenzen. Vielleicht hat dort wer "0 Sekunden" eingetragen (bin kein Admin, weiß also nicht ob das so überhaupt möglich ist)...
-
Oder vielleicht doch Rechte?
Hatte heute selbst den Fall, dass ein Agent (also die ID) auf die Dokumente, die er verarbeiten sollte kein Leserecht hatte. Somit war der Agent der Meinung er hätte nichts zu verarbeiten und hat deshalb auch kein Protokolldokument erstellt (ich bin da sparsam).
Unter meiner ID (also händisch gestartet) hat es dagegen immer funktioniert.
-
Ich glaube, 0 Sekunden nimmt uns der Domino nicht ab - da fühlt er sich verarscht. Sicher bin ich mir da aber nicht.
Ansonsten: Auf dem Domino findet Du auf jeder der zahlreichen viele Log-Einträge des Agent-Managers. Der tut. Und die meisten Agents sind ... aber das hatte ich schon geschrieben.
Trotzdem vielen Dank für's Mitdenken, Mitch. Es muss was ganz billiges sein. Aber das ist es nicht.
Bernhard
-
Wie ich schon schrieb: Der Agent läuft manuell mit der gleichen ID. Die hat Gott-Status in der DB, der entgeht nichts ;)
Bernhard
-
Wie sieht es mit anderen sceduled Agenten aus?
Laufen die?
-
Wie ich schon schrieb: Der Agent läuft manuell mit der gleichen ID. Die hat Gott-Status in der DB, der entgeht nichts ;)
Bernhard
Dann ist doch aber der einzige Unterschied, die Umgebung. Also manuell gestartet im Clientkontext und scheduled im Serverkontext.
Unterscheidet sich da ggf. Server A von Server B (Laufwerke, Umgebungsvariablen, weiss der Geier)
-
In anderen Datenbanken: Ohne Fehl und Tadel. Diese Datenbank hat nur zwei - und beide zeigen den gleichen Effekt. Nämlich gar keinen.
Danke, Andre. Vielleicht ergibt sich ja über diese Schiene etwas. Aber was? Inaktivierung von Hintergrund-Agenten? Dann würde das Protokoll nichts anzeigen, und nein: Da ist auch kein Haken gesetzt.
Bernhard
-
Thomas: Die Dominos unterscheiden sich da nicht. Es wird auch auf nix derartiges zugegriffen - es werden Dokumente in der gleichen DB überprüft und ggf. Mails verschickt.
Aber nochmals: Der Agent springt kurz an, bricht aber sofort wieder ab. Fehlerfreies Agent-Protokoll, Start und Ende in der gleichen Sekunde, aber kein Eintrag im Server-Log. Sowas kenne ich von Frontend-Elementen in scheduled agents (aber m.E. zeigt da dann auch das Agent-Protokoll nichts an).
Bernhard
-
Weitergestochert:
Ziel des Agenten auf "Neue oder geänderte Dokumente"? Dann ist vielleicht was mit dem Server-Datum nicht in Ordnung (z.B. in ferner Zukunft und daher denkt er es ist nichts zu tun)?
-
Du schreibst, dass der zweite Agent in der DB das gleiche Problem hat.
Also irgendwas grundsätzliches mit der DB?
Was sagt denn eigentlich "tell amgr sched"?
-
Mitch: Nein, das Ziel ist "Alle Dokumente in der Datenbank"!
Thomas: Da kommt die korrekte Ansage.
ABER:
Ich wusste, ich bin blind oder sehe zumindest nix mehr. Ich habe doch tatsächlich wie ein Vollposten im falschen Log nachgeschaut. Und was steht im richtigen Log?
08.12.2011 14:34:42 Agent Manager: Error in Agent 'Newsletter' in database 'XXX.nsf' signed by 'XXX/USER/XXX' calling script library 'AgentCodeLib'. Script library signature is corrupted.
08.12.2011 14:34:42 AMgr: Agent ('Newsletter' in 'XXX.nsf') error message: Error loading USE or USELSX module: AgentCodeLib
Und darauf greifen beide Agents zu ... Irgendwas muss da beim Schablonen-Update schief gelaufen sein.
Entschuldigt bitte vielmals! Ich wusste, es wird peinlich ...
Hochrot,
Bernhard
-
Am Ende wird doch alles immer gut.
-
Vielleich noch etwas Sinnfreies, was passiert mit einer Ausgabe im Terminate des Agenten?
Wenn man mehrer Hundert Kacheln hat, kann man schonmal das falsche Log erwischen ;D
Egal, Sorgenkind gefunden
-
Danke für die tröstenden Worte. Ich bin trotzdem ein Depp! Umso schlimmer, dass ich in dieser Richtung schon überlegt habe: Was mag der Agent nicht, dass er gar nicht erst anspringt? Aber wenn man dann im falschen Log nachschaut ... Das ist ja wie lokal entwickeln und am Server testen (ist mir natürlich auch schon passiert! Wenn auch viele Jahre her ist ...)
Und jetzt tun natürlich beide Agenten, wie sie sollen. Danke Euch allen!
Bernhard
-
Gestern haben wir zum ersten Mal Agenten auf unserem neuen Server getestet. Ich schau ins (eigene) Log, nix, der läuft nicht. Nochmal deaktiviert, wieder aktiviert. Er tut es ums verrecken nicht.
Lösung: Ins Log des alten Servers (in das ich geschaut hatte) kommen die Dokumente natürlich erst mit der nächsten Replikation, die im Augenblick wohl stündlich läuft (bis wir die alten Maschinen abstellen).
Also keine 24 Stunden her, habe ich ziemlich genau das gleiche gemacht (leider war ich lange am Telefon, sonst hätte ich meine "Erfahrung" früher einbringen können).
Ein Trost für Dich? Zumindest bist Du nicht der einzige Depp, willkommen im Club! ;)
-
Ja, Peter: Das ist ein Trost! Vor allem, da ich solche Konstrukte wie Deines kenne. Das habe ich alles auch schon erlebt (siehe ach vorige Posts). Wir sind halt nur Menschen, auch wenn unsere Welten (IT-technisch gesehen) schon erheblich komplexer sind als bei vielen anderen.
Was wir aber daraus lernen (und das sollten wir ja eigentlich schon aus purer Erfahrung tun, in Österreich gibt es dafür den herrlich treffenden Begriff "Hausverstand"):
- Beschreibe Dein Problem so gut es Dir möglich ist. Beziehe Nebenbedingungen mit ein! (Mein Fehler 1: "Im Log steht nix!" Es war halt nur das falsche Log ...)
Ich denke, ich habe da nicht ganz unperfekt gehandelt. Das mangelt aber leider manchen Anfängern, wozu auch Nutzer gehören, die schon Jahre dabei sind: "Plan aufmalen, Analyse betreiben, Rahmenbedingungen feststecken - und das alles bekannt geben!, Lösung andenken und zur Diskussion stellen
2. Ziehe mehrere Ursachen in Betracht, die dann erst zum "miesen Zustand" führen. Folge nicht dem ersten Verdacht, sondern stufe ihn - auch wenn es schwer fällt - als "ein möglicher" ein! Kann ja stimmen - muss aber nicht.
Auch andere Branchen haben das zu bieten: De facto kein Flugzeug legt einen "nicht beabsichtigten Bodenkontakt" hin, nur weil ein einziger Fehler gemacht wurde.
Beispiel: LOT-Flug nach Warschau mit Boeing 767, in aller Munde wegen der Tatsache, dass die Piloten (das macht dann freiwillig niemals einer!) das Riesenteil dann mit nicht ausfahrbarem Fahrwerk eben mit einer "Bauchlandung" dann sicher und sauber in Warschau herunter gebracht haben.
Aber: Zwei Ursachen waren es wieder!
- Der Hydraulikteil des Fahrwerks gab schon nach dem Start seinen Geist auf (sauberer: Da wurde es offensichtlich).
- Die Ersatzmechanik für das Ausfahren des Fahrwerks funktionierte nicht. Die der Besatzung zur Verfügung stehenden Checklisten haben - mein Kenntnisstand bis hierher - auch nichts erbracht, also bereitete man sich nach der Atlantiküberquerung auf eine Landung in Warschau ohne Hauptfahrwerk vor (was die Besatzung auch ganz sauber hin bekommen hat).
Jetzt stellt sich aber heraus, das neben dem Ausfall der Center Hydraulics auch ein "harmloser" C/B / circuit braeker = Sicherung seit "irgendwann" herausgefallen war: "C829 BAT BUS DISTR" ist aber zuständig u.a für das alternative Ausfahren des Fahrwerks.
Das hätte mindestens die Technik am Boden als Möglichkeit annehmen müssen (die Crew hatte - wie geschrieben - hierfür keine Manuals, hätte aber auch mal alle C/B-boards durchsehen können), aber man kaprizierte sich offensichtlich auf ein ganz anderes Problem, was es gar nicht gab.
Wie auch immer: Der LOT-Flug war viel dramatischer als der Ausfall meines "nice-to-have-"-Agents, aber die Denk-Schemata waren schon irgendwie vergleichbar.
Sorry für den langen Exkurs,
Bernhard