Jitterbit Private Agent Fehlersuche

Einführung

Diese Seite bietet Fehlersuche für verschiedene Probleme, die beim Ausführen eines privaten Agents auftreten können. Kontaktieren Sie den Jitterbit-Support für Probleme, die hier nicht aufgeführt sind.

Benutzerdefinierte API gibt 504 zurück, aber das Betriebsprotokoll zeigt Erfolg

Problem

Eine benutzerdefinierte API gibt einen 504 Gateway-Timeout zurück, aber das Betriebsprotokoll auf der Seite Runtime der Management-Konsole zeigt an, dass der Vorgang erfolgreich abgeschlossen wurde.

Ursache

In einigen Fällen versucht ein privater Agent, die Anforderungsnutzlast vom Host jitterbitsysservice für seine Region abzurufen, unabhängig davon, ob das API-Gateway die Nutzlast getrennt hat. Wenn der Host-Computer des Agents diesen Host nicht erreichen kann, läuft der Abruf ab und die API gibt einen 504 zurück, obwohl der Vorgang selbst ausgeführt wurde.

Die Standardverbindungskontrolle des Agents überprüft nicht die Konnektivität zum Host jitterbitsysservice, sodass der Agent vollständig verbunden erscheinen kann, während dieser Host blockiert bleibt.

Lösung

Fügen Sie die URL des Hosts jitterbitsysservice und seine statischen IP-Adressen für Ihre Region zur ausgehenden Zulassungsliste der Firewall des Host-Computers des privaten Agents hinzu. Weitere Informationen zu regionsspezifischen URLs und IPs finden Sie auf der Seite Jitterbit-Zulassungsliste Informationen.

Überprüfen Sie nach dem Aktualisieren der Zulassungsliste die Konnektivität, indem Sie einen HTTP-Test vom Agenten-Host zur URL jitterbitsysservice für Ihre Region durchführen und bestätigen, dass die API nicht mehr abläuft.

Jitterbit Private Agent läuft nicht oder ist gestoppt oder nicht erreichbar

Die Fehlermeldung Agent Not Running or Unreachable kann durch folgende Faktoren verursacht werden:

• Sie verwenden eine ältere Version des Agents.

  Lösung: Aktualisieren Sie auf die neueste Version des Agents.

• Die Jitterbit-Dienste laufen nicht.

  Lösung: Dienste können in %windir%\system32\services.msc gestartet werden; ODER

  

  

  Lösung: Im Installationsverzeichnis finden Sie ein StartServices.bat-Skript, das die relevanten Dienste startet; ODER

  

  Lösung: Für Windows finden Sie im Startmenü die Option Jitterbit-Dienste starten.

  

  In der Regel finden Sie einen Fehler während des Neustarts, wenn ein Dienst nicht startet.

  • Für Windows: Suchen Sie nach einem Fehler in C:\Program Files (x86)\Jitterbit Agent\log. Stellen Sie sicher, dass sie als Lokales System ausgeführt werden, und überprüfen Sie das Ereignisprotokoll auf Fehlermeldungen.

  • Für Linux: Suchen Sie nach einem Fehler in /opt/jitterbit/log.

  Hinweis

  Ersetzen Sie USERNAME durch Ihren aktuellen Benutzernamen.

  Berechtigungen: Das Konto, unter dem die Jitterbit-Dienste ausgeführt werden, muss ein lokaler Administrator auf dem Computer sein und vollen Zugriff auf den Jitterbit-Ordner haben.

• Dienste laufen, können jedoch nicht mit Jitterbit Cloud kommunizieren.

  Lösung: Überprüfen Sie:

  • Ob das Internet funktioniert.

  • Die Protokolldatei, um zu sehen, ob es eine offensichtliche Fehlermeldung gibt:

    • Für Windows: C:\Program Files (x86)\Jitterbit Agent\log\jitterbit-agent.log.

    • Für Linux: /opt/jitterbit/log/jitterbit-agent.log.

• Proxy-Probleme können ebenfalls die Fehlermeldung Agent Not Running oder Unreachable verursachen. Die Fehlersuche ist etwas schwieriger, da es so viele verschiedene Netzwerk-Konfigurationen gibt.

  Lösung: Während der Installation müssen Sie möglicherweise die Option Negotiate Ntlm Proxy aktivieren oder deaktivieren. Dies hängt davon ab, welchen Proxy Sie verwenden. Es ist auch sehr hilfreich, das Verweigerungsprotokoll vom Proxy-Server zu sehen.

Jitterbit privater Agent zeigt unterschiedliche Versionen oder IPs

Problem

Die Agenten Seite in der Management-Konsole kann unterschiedliche Versionen und/oder IPs für einen privaten Agenten anzeigen. Nach dem Neustart der Agentendienste kann die Agenten-Seite zunächst die "korrekte" Version/IP anzeigen und dann wiederholt hin und her wechseln.

Ursache des Problems

Der Agent-Server wurde wahrscheinlich geklont. Der geklonte Server läuft parallel und kollidiert mit dem Haupt-Agent-Server. Es ist nicht möglich, mehrere Server unter denselben Agent-Anmeldeinformationen auszuführen.

Schritte zur Fehlersuche und Behebung

1. Schalten Sie die Hauptserver-Maschine, die die offizielle Version ausführt, aus, warten Sie 10 Minuten und aktualisieren Sie dann die Seite Agents im Management Console. Wenn der Status des Agents von gestoppt auf laufend wechselt, bedeutet dies, dass eine andere Instanz des Agents läuft. Die Agents arbeiten entweder abwechselnd oder gleichzeitig.

2. Um das Problem zu beheben, ist es notwendig, die Instanz zu finden, die unter der alten Version läuft, und diesen Server auszuschalten.

3. Wenn Sie das nicht tun können, deinstallieren Sie den offiziellen Agenten, erstellen Sie einen neuen Agenten mit einem anderen Namen und installieren Sie ihn auf dem offiziellen Server.

4. Überprüfen Sie, ob der neue Agent läuft, wie auf der Seite Agents im Management Console aufgeführt.

5. Löschen Sie den alten Agenten von der Seite Agents über das Dropdown Action > Remove.

Verbindungs-, Websocket- und I/O-Fehler bei Jitterbit-Privatagenten, die Azure-VMs verwenden

Übersicht

Diese Seite bietet Anweisungen zur Fehlersuche bei einem auf einer Microsoft Azure-virtuellen Maschine (VM) installierten Linux- oder Windows-Privatagenten. (Siehe Leistungsoptimierung für Privatagenten für allgemeine Informationen zur Leistungsoptimierung.)

Fehlersuche bei verlorenen Verbindungen

Bei der Verwendung eines auf einer Microsoft Azure-VM installierten Privatagenten können Sie verlorene Verbindungen erleben. Azure setzt die WebSocket-Leerlaufzeit auf 4 Minuten, während der Standardwert für den Ping an Harmony beim privaten Agenten auf 5 Minuten eingestellt ist. Um dieses Problem zu beheben, reduzieren Sie das Intervall für den Agenten-Herzschlag:

1. Öffnen Sie die Datei jitterbit-agent-config.properties in einem Texteditor. Diese Datei befindet sich in den folgenden Verzeichnissen:

   • Linux: <JITTERBIT_HOME>/Resources/

   • Windows: C:\Program Files\Jitterbit Agent\Resources

2. Finden Sie die Einstellung agent.heart.beat.interval:

   #Agent Herzschlagintervall (IN MINUTEN)
   agent.heart.beat.interval=5
   

3. Ändern Sie die Einstellung in agent.heart.beat.interval=3.

4. Speichern Sie die Änderungen und starten Sie den Agenten neu.

Fehlerbehebung bei Websocket- und I/O-Fehlern

Fehler im Zusammenhang mit WebSocket und I/O können durch Aktualisierungen der zugehörigen IP-Leerlaufzeit des VMs, der TCP-Leerlaufzeit des NAT-Gateways und der Flusszeitüberschreitungen des virtuellen Netzwerks (VNET) behoben werden.

Die Werte für die IP-Leerlaufzeit, die TCP-Leerlaufzeit des NAT-Gateways und die VNET-Flusszeit müssen alle auf 15 Minuten eingestellt werden.

Relevante Fehler identifizieren

WebSocket- und I/O-Fehler können durch Verweis auf die Betriebsprotokolle und die Datei jitterbit-agent.log identifiziert werden. Diese Protokolldatei befindet sich an einem der folgenden Speicherorte:

• Für Windows: C:\Program Files (x86)\Jitterbit Agent\log\jitterbit-agent.log.

• Für Linux: /opt/jitterbit/log/jitterbit-agent.log.

Fehler im Betriebsprotokoll

Falls vorhanden, können folgende Nachrichten in den Betriebsprotokolldetails für einen Vorgang mit dem Status Fehler auf einen WebSocket- oder I/O-Fehler hinweisen:

Der Vorgang "Beispielvorgang" wurde erfolgreich abgeschlossen.

Keine Nachricht gefunden, während die Nachricht im Cache entfernt wurde für: Nachrichteninfo: AgentId: 000001 AgentGroupId: 000001 MessageId: XXX Nachrichtenversion (Agent): XXXX Nachrichtenversion (Harmony): XXX Zähler (Harmony): 1 Eingereichtes Zeitstempel (Harmony):2024-01-20 11:55:00.700 , Nachricht wird später erneut versucht OperationInstanceGUID: XXX

Die Ausführungsnachricht konnte den Agenten nicht erreichen.

Fehler in der Agent-Protokolldatei

Falls vorhanden, können folgende Nachrichten in der Datei jitterbit-agent.log auf einen WebSocket- oder I/O-Fehler hinweisen:

2024-01-20 12:00:00 Anforderungsbehandlungs-Thread #10642  INFO org.jitterbit.integration.server.api.util.AgentRetryExecutor:53 - Empfang der Agentennachricht (OperationInstanceGUID: XXX) fehlgeschlagen. Erneuter Versuch....
2024-01-20 12:00:00 Anforderungsbehandlungs-Thread #10642 ERROR org.jitterbit.integration.server.api.util.AgentRetryExecutor:55 - org.springframework.web.client.ResourceAccessException: I/O-Fehler bei PUT-Anforderung für "https://na-east.jitterbit.com/jitterbit-cloud-restful-service/agent/ackmsgreceipt": Lesezeitüberschreitung; geschachtelte Ausnahme ist java.net.SocketTimeoutException: Lesezeitüberschreitung

E:2024-01-20 12:00:00 request handler thread #884 FEHLER org.jitterbit.integration.server.messaging.agent.listener.AgentMessageListener:231 - Keine Nachricht gefunden beim Entfernen der Nachricht im Cache für: Nachrichteninfo: AgentId: 000001 AgentGroupId: 000001 MessageId: XXX Nachrichtenversion (Agent): XXXX Nachrichtenversion (Harmony): XXX Zähler (Harmony): 1 Eingereichtes Zeitstempel (Harmony):2024-01-20 11:55:00.700 , Nachricht wird später erneut versucht OperationInstanceGUID: XXX

Drain stop the agent

Drain stop den Agenten, bevor Sie irgendwelche Timeout-Einstellungen aktualisieren. Wenn Sie mehr als einen Agenten in der betroffenen Agentengruppe haben, tun Sie dasselbe für alle.

Isolate agent resources

Es wird empfohlen, dass die VM des Agenten und die zugehörigen Ressourcen in ihre eigene Ressourcengruppe in Azure getrennt werden. Dazu gehören das VNET, die IP, das NAT-Gateway, die Netzwerkschnittstelle (NIC) und die Netzwerksicherheitsgruppe (NSG), falls vorhanden.

Update the IP's idle timeout

1. Navigieren Sie im Azure-Portal zur Ressourcengruppe, die mit der VM des Agenten verbunden ist.

2. Identifizieren und klicken Sie auf das IP-Element, das mit der VM verbunden ist:

   

3. Klicken Sie auf Konfiguration und ändern Sie den Wert für Inaktivitätszeitüberschreitung (Minuten) auf 15 Minuten:

   

Update the NAT gateway's TCP idle timeout

1. Navigieren Sie im Azure-Portal zur Ressourcengruppe, die mit der VM des Agenten verbunden ist.

2. Identifizieren und klicken Sie auf das NAT-Gateway-Element, das mit der VM und der IP verbunden ist, falls vorhanden. Ein zugehöriges NAT-Gateway wird auch im Überblick des IP-Elements neben dem Feld Zugeordnet zu aufgeführt.

3. Klicken Sie auf Konfiguration und ändern Sie den Wert für TCP-Inaktivitätszeitüberschreitung (Minuten) auf 15 Minuten.

Aktualisieren des Flow-Timeouts des VNET

1. Navigieren Sie im Azure-Portal zur Ressourcengruppe, die mit der VM des Agents verbunden ist.

2. Identifizieren Sie das VNET-Element, das mit der VM verbunden ist, und klicken Sie darauf:

   

3. Klicken Sie in Übersicht neben Flow-Timeout auf Konfigurieren:

   

4. Aktivieren Sie im Bereich Flow-Timeout die Einstellung Flow-Timeout aktivieren und ändern Sie den Wert für Flow-Timeout (Minuten) auf 15 Minuten:

   

5. Klicken Sie auf Speichern.

Agent neu starten

1. Starten Sie im Azure-Portal die VM des Agents neu.

2. Starten Sie den gestoppten Agenten neu. Siehe entweder Einen Windows-Agenten neu starten oder Einen Linux-Agenten neu starten für detaillierte Informationen.

Fehler 1722 mit Windows Jitterbit privaten Agenten

Problem

Die Installation des Windows-Privatagenten schlägt mit dieser Fehlermeldung fehl:

Fehler 1722. Es gibt ein Problem mit diesem Windows Installer-Paket. Ein Programm, das im Rahmen der Installation ausgeführt wurde, wurde nicht wie erwartet beendet. Kontaktieren Sie Ihr Supportpersonal oder den Paketanbieter. ...

Ursache und Lösung des Problems

Es gibt mehrere Gründe, warum die Installation des Privatagenten mit dieser Fehlermeldung fehlschlagen könnte. Zwei der häufigsten Gründe sind ein Konflikt mit dem Microsoft Visual C++ Redistributable oder das Vorhandensein verbotener Zeichen im PostgreSQL-Passwort.

Microsoft Visual C++ Redistributable

Ein Konflikt mit einer vorhandenen Version des Microsoft Visual C++ Redistributable kann Fehler 1722 verursachen.

Private Agenten erfordern, dass Microsoft Visual C++ Redistributable für Visual Studio installiert ist, bevor ein privater Agent installiert wird. Microsoft stellt die gleichen redistributierbaren Dateien für Visual Studio C++ 2015, 2017 und 2019 zur Verfügung. Installieren Sie die 64-Bit-Windows-Version mit vc_redist.x64.exe.

Verbotene PostgreSQL-Passwortzeichen

Ein PostgreSQL-Passwort, das verbotene Zeichen verwendet, kann zu Fehler 1722 führen.

Um dieses Problem zu lösen, ändern Sie das Passwort in ein gültiges.

IPv6-Probleme bei Windows Jitterbit privaten Agenten

Übersicht

Einige Kunden haben Probleme festgestellt, wenn das Internetprotokoll der Version 6 (IPv6) aktiviert ist. In diesen Fällen empfehlen wir, IPv6 und IP Helper zu deaktivieren.

IPv6 deaktivieren

Um IPv6 zu deaktivieren:

1. Öffnen Sie unter Windows die Systemsteuerung > Netzwerk und Internet > Netzwerkverbindungen.

2. Öffnen Sie die Eigenschaften einer Verbindung.

3. Deaktivieren Sie das Kontrollkästchen für Internetprotokoll Version 6 (TCP/IPv6):

   

IP Helper deaktivieren

Um IP Helper zu deaktivieren:

1. Öffnen Sie unter Windows Dienste.

2. Suchen Sie IP Helper in der Liste der Dienste. Klicken Sie dann mit der rechten Maustaste auf IP Helper und wählen Sie Eigenschaften.

3. Klicken Sie in den Eigenschaften von IP Helper auf Stop, um den Dienst zu stoppen, und ändern Sie den Starttyp auf Deaktiviert:

   

Apache-Serverfehler bei Jitterbit privaten Agenten

Wenn Sie diese Fehlermeldung erhalten:

No Installed ConfigArgs for the Service "Jitterbit Apache Server"

Bedeutet dies, dass der Benutzer, unter dem der Jitterbit Apache-Server läuft, keinen vollständigen Zugriff auf den Jitterbit-Ordner hat.

PostgreSQL-Dienst nach fehlgeschlagenem Upgrade unter Windows entfernt

Problem

Nach einem fehlgeschlagenen Upgrade des privaten Agenten unter Windows erscheint der PostgreSQL-Dienst (postgresql-x64-<VERSION>) nicht mehr in den Windows-Diensten, und die Jitterbit-Agentdienste können aufgrund fehlender Abhängigkeiten nicht gestartet werden.

Dies kann bei privaten Agentenversionen vor 11.59 / 12.3 auftreten, wenn während des Upgrades ein falsches Passwort eingegeben wird und der Installer nicht korrekt zurückrollt.

Auflösung

Um den PostgreSQL-Dienst erneut zu registrieren und den Agenten ohne Deinstallation wiederherzustellen, befolgen Sie diese Schritte:

1. Öffnen Sie eine Eingabeaufforderung als Administrator.

2. Registrieren Sie den PostgreSQL-Dienst erneut:

   "C:\Program Files\PostgreSQL\<VERSION>\bin\pg_ctl.exe" register -N "postgresql-x64-<VERSION>" -D "C:\Program Files\PostgreSQL\<VERSION>\data"
   

   Ersetzen Sie <VERSION> durch die Versionsnummer von PostgreSQL in Ihrer Installation. Um Ihre Version zu finden, siehe PostgreSQL-Version, die mit dem privaten Agenten gebündelt ist.

3. Starten Sie die PostgreSQL- und PgBouncer-Dienste:

   net start postgresql-x64-<VERSION>
   net start JitterbitPgbouncer
   

4. Starten Sie alle Jitterbit-Agentendienste:

   "C:\Program Files\Jitterbit Agent\StartServices.bat"
   

5. Sobald der Agent wieder läuft, setzen Sie die Passwörter für das PostgreSQL-Admin- und Dienstkonto zurück, bevor Sie den Upgrade-Versuch erneut starten.

PostgreSQL-Fehler bei Windows Jitterbit privaten Agenten

Problem

In bestimmten Fällen, nachdem ein Windows-Privatagent deinstalliert wurde und anschließend versucht wird, den Agenten erneut zu installieren, können Benutzer eine Fehlermeldung erhalten, die mit der PostgreSQL-Datenbank zusammenhängt.

Ursache des Problems

Dieser Fehler ist bekannt dafür, auf Systemen aufzutreten, bei denen die mit dem privaten Agenten verbundene PostgreSQL-Installation nicht vollständig entfernt wurde.

Auflösung

Um den Fehler zu beheben, sollten die Benutzer die in Einen Windows-Privatagenten deinstallieren beschriebenen Schritte befolgen, um das Jitterbit PostgreSQL-Benutzerkonto vollständig zu entfernen.

Sobald dies erledigt ist, sollten Sie in der Lage sein, eine neue Agenteninstallation abzuschließen. Wenn Sie weiterhin Probleme haben, wenden Sie sich bitte an den Support.

Installation von 64-Bit Windows Jitterbit privaten Agenten mit Zwei-Faktor-Authentifizierung (TFA) nicht möglich

Problem

Es ist ein bekanntes Problem, dass 64-Bit Windows private Agenten nicht installiert werden können, wenn die Zwei-Faktor-Authentifizierung (TFA) aktiviert ist. Wenn TFA aktiv ist, schlägt die Installation eines 64-Bit Windows privaten Agenten fehl und es wird ein Fehlerdialog angezeigt.

Lösung

Um dieses Problem zu umgehen, deaktivieren Sie vorübergehend TFA und installieren Sie den 64-Bit Windows privaten Agenten. Nach der Installation aktivieren Sie TFA erneut.

TFA kann in den Einstellungen der Organisation deaktiviert und aktiviert werden, die über die Seite Organisationen der Management-Konsole aufgerufen werden kann.

Fehler bei Verbindungsslots mit Windows 64-Bit Jitterbit privaten Agenten

Problem

Dieser Fehler tritt bekanntlich bei Windows 64-Bit privaten Agenten auf, die vor der Harmony 10.14-Version installiert wurden:

Failed to connect to back-end database "TranDb"
FATAL: remaining connection slots are reserved for non-replication superuser
connections
(0) SQL Error! SQLSTATE = 53300 Native err = 210 msg = FATAL: remaining connection slots are reserved for non-replication superuser connections
(1) SQL Error! SQLSTATE = IM006 Native err = 0 msg = [Microsoft][ODBC Driver Manager] Driver's SQLSetConnectAttr failed
Details:
Unable to connect to database using connection string:
UID=jitterbit;PWD=<REMOVED>;SERVER=127.0.0.1;DRIVER={PostgreSQL ODBC
Driver(UNICODE)};DATABASE=TranDb;Port=6543;!

Lösung

Um dieses Problem zu beheben, erhöhen Sie die Einstellungen max_connections und checkpoint_timeout in der Datei postgresql.conf auf dem Windows 64-Bit privaten Agenten, indem Sie die folgenden Schritte ausführen:

1. Erstellen Sie eine Sicherungskopie Ihrer Datei postgresql.conf und speichern Sie sie an einem anderen Ort. Diese Datei befindet sich im Verzeichnis C:\Program Files\PostgreSQL\*\data.

2. Öffnen Sie die Datei postgresql.conf in einem Texteditor.

3. Suchen Sie die Einstellung max_connections.

   # - Connection Settings -
   
   listen_addresses = '*'      # what IP address(es) to listen on;
                       # comma-separated list of addresses;
                       # defaults to 'localhost'; use '*' for all
                       # (change requires restart)
   port = 6543             # (change requires restart)
   max_connections = 100           # (change requires restart)
   #superuser_reserved_connections = 3 # (change requires restart)
   #unix_socket_directories = ''   # comma-separated list of directories
   

4. Ändern Sie diese Einstellung in max_connections = 400.

5. Suchen Sie die Einstellung checkpoint_timeout.

   # - Checkpoints -
   
   #checkpoint_timeout = 5min      # range 30s-1d
   #max_wal_size = 1GB
   #min_wal_size = 80MB
   

6. Ändern Sie diese Einstellung in checkpoint_timeout = 1h und löschen Sie das Kommentarzeichen (#) am Anfang der Zeile.

7. Speichern Sie Ihre Änderungen und starten Sie den Agenten neu.

Wiederherstellung einer fehlgeschlagenen privaten Agenteninstallation unter Windows

Problem

Die Installation oder das Upgrade eines privaten Agenten unter Windows schlägt fehl.

Auflösung

Aufgrund der Vielzahl möglicher Ursachen ist die einfachste Lösung, die private Agentensoftware vollständig zu deinstallieren und dann neu zu installieren, wenn ein Teil des Installations- oder Upgrade-Prozesses fehlschlägt.

Fehler bei der Installation ohne Root-Rechte unter Linux

Wenn Sie Probleme bei der Installation eines privaten Agents unter Linux mit dem Linux Redhat Non-Root (x64) Installationspaket haben, überprüfen Sie, ob Folgendes zutrifft:

• Der nicht-root Benutzer, der die Installation durchführt, hat sudo-Rechte. Der übliche Weg, dies sicherzustellen, besteht darin, einen Systemadministrator zu bitten, den Benutzer zur wheel-Gruppe hinzuzufügen. Um zu überprüfen, in welchen Gruppen der Benutzer ist, führen Sie den Befehl groups aus.

• Wenn Sie als jitterbit-Benutzer angemeldet sind, ist die Umgebungsvariable JITTERBIT_HOME auf den Installationsort gesetzt. Um dies zu überprüfen, führen Sie diesen Befehl als jitterbit aus:

  echo $JITTERBIT_HOME
  

  Das Ergebnis sollte /opt/jitterbit sein. Dies wird durch die Bash-Umgebungsdatei des Benutzers jitterbit $HOME/.bashrc.d/jitterbit gesetzt, wenn Sie die Installationsanweisungen befolgt haben. Wenn nicht, können Sie die Umgebung schnell mit diesem Befehl setzen:

  . /opt/jitterbit/scripts/set.env
  

Wenn die Installation zu einem OPENSSL_3.4.0-Fehler führt, handelt es sich um ein bekanntes Problem bei RHEL 9.7 und später. Siehe RHEL 9.7 und spätere Installation des privaten Agents ohne Root-Rechte zeigt einen OpenSSL-Fehler in den bekannten Problemen des privaten Agents für eine Lösung.

Docker-Fehlerbehebung

Allgemein

Die folgenden allgemeinen Punkte können bei Docker-bezogenen Problemen hilfreich sein:

• Ein Docker-privater Agent startet nicht, wenn das Verzeichnis conf sowohl eine Datei credentials.txt als auch eine Datei register.json enthält.

• Docker-Agents verwenden die Standardeinstellungen in der jitterbit.conf-Datei des Images. Ohne Persistenz gehen alle Änderungen, die Sie an dieser Datei innerhalb des Containers vornehmen, verloren, wenn der Container stoppt. Um Ihre eigenen Einstellungen zu verwenden, legen Sie diese in conf/jitterbit.conf ab. Diese Datei wird beim Start in den Container kopiert und überschreibt die Standarddatei.

Containerisierter Agent kann aufgrund von Authentifizierungsfehlern nicht neu gestartet werden

Wenn Ihr containerisierter Agent mit deregisterAgentOnDrainstop=true (oder der entsprechenden Umgebungsvariable AUTO_REGISTER_DEREGISTER_ON_DRAINSTOP) konfiguriert wurde und ein persistentes Volume für das Verzeichnis /opt/jitterbit/Resources des Containers verwendet, kann es sein, dass er nach dem Stoppen nicht neu gestartet werden kann.

Dies geschieht, weil der Agent beim Stoppen des Containers mit deregisterAgentOnDrainstop=true sich von Harmony abmeldet, die nun ungültige Datei credentials.txt jedoch im persistenten Volume verbleibt. Beim Neustart versucht der Agent, diese veralteten Anmeldeinformationen zu verwenden, und kann sich nicht authentifizieren.

Um dies zu beheben, müssen Sie die Datei credentials.txt manuell aus dem Volume entfernen. Sie können dies mit dem folgenden Befehl tun:

docker run -i --rm -v VOLUME_NAME:/opt/jitterbit/Resources jitterbit/agent rm -i /opt/jitterbit/Resources/credentials.txt

• VOLUME_NAME: Das Docker-Volume, unter dem das persistente Verzeichnis /opt/jitterbit/Resources gemountet wurde.

Nachdem Sie die Datei entfernt haben, starten Sie den privaten Agenten-Container neu, um eine neue Registrierung zu starten.