Scheduled Agent startet nicht (auf einem Server)

[koehlerbv]

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

[tks]

Auch wenn du das höchstwahrscheinlich geprüft hast:

steht denn unter Zeitplan -> auführen auf der richtige Server drin?

[koehlerbv]

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

[Driri]

Im Agenten ist aber kein Run on behalf eingestellt ?

[koehlerbv]

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

[Mitch]

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)...

[tks]

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.

[koehlerbv]

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

[koehlerbv]

Wie ich schon schrieb: Der Agent läuft manuell mit der gleichen ID. Die hat Gott-Status in der DB, der entgeht nichts 

Bernhard

[DerAndre]

Wie sieht es mit anderen sceduled Agenten aus?
Laufen die?

[tks]

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)

[koehlerbv]

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

[koehlerbv]

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

[Mitch]

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)?

[tks]

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"?

[koehlerbv]

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

[tks]

Am Ende wird doch alles immer gut.

[DerAndre]

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  

Egal, Sorgenkind gefunden

[koehlerbv]

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

[Peter Klett]

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!