JTL Worker 2.0 hängt oder startet nicht — die häufigsten Ursachen und wie du sie behebst

Auf einen Blick

• ✓Der häufigste Grund warum der JTL Worker 2.0 nach einem Neustart nicht anspringt: Das Windows-Passwort im Dienst-Konto passt nicht mehr oder der Starttyp steht nicht auf „Automatisch (verzögert)“. Wir räumen diese Konfigurationsfehler regelmäßig bei Kundensystemen auf.
• ✓Hängende Abgleiche entstehen meist beim Shop- oder eBay-Prozess. Der Dienst selbst läuft, aber der einzelne Client-Prozess ist zum Zombie geworden. Die Lösung: gezielt den Worker-Client-Prozess beenden, nicht den ganzen Dienst neu starten.
• ✓Dauerhaft stabil wird es durch einen eigenen JTL-Worker-Benutzer ohne Passwort-Ablauf, Starttyp „verzögert“ und ein Monitoring auf die Worker.tStatus-Tabelle in der Datenbank. Wir richten das bei Bedarf für dich ein.

Ein hängender Worker ist für einen Händler kein technisches Detail, sondern ein Betriebsausfall. Als JTL Service Partner Gold aus Ahrensfelde bei Berlin haben wir das täglich auf dem Tisch und in über 300 Kundenprojekten gelernt, wo die Fehler wirklich stecken. Nicht im Worker selbst, sondern fast immer in der Einrichtung des Windows-Dienstes drumherum.

Der JTL Worker 2.0 ist die zentrale Automatisierungsschicht in JTL-Wawi. Laut JTL-Dokumentation zieht er Bestellungen aus Onlineshop und Marktplätzen, synchronisiert Bestände, aktualisiert Währungskurse über die Europäische Zentralbank und fährt weitere zeitgesteuerte Hintergrundprozesse. Für einen Multichannel-Händler läuft der Dienst rund um die Uhr. Eine Stunde Ausfall heißt im Zweifel: Bestellungen landen im Shop, aber nicht in der Wawi.

Aus eigenen Projektdaten: In mehr als der Hälfte unserer Worker-Supportfälle ist nicht der Worker das Problem, sondern ein falsch konfigurierter Windows-Dienst oder ein abgelaufenes Benutzer-Passwort. Diese Fälle lassen sich bei bekanntem Muster schnell eingrenzen — eine Einschätzung gibt es nach dem Erstgespräch.

Die häufigsten Auslöser aus unserer Praxis:

• →Falsches Windows-Passwort im Dienst: Beim Einrichten des Windows-Dienstes wird das aktuelle Passwort gespeichert. Ändert sich das Windows-Konto-Passwort später, startet der Dienst nicht mehr. Windows prüft das Passwort erst beim Start des Dienstes, nicht beim Einrichten.
• →Starttyp ist nicht ‚Automatisch (verzögert)‘: Der Worker-Dienst startet zu früh im Boot-Vorgang, bevor die SQL-Datenbank bereit ist. Dann bricht der Dienst sofort ab und Windows versucht es nicht nochmal. Richtiger Starttyp: ‚Automatisch (verzögert)‘.
• →Kein dedizierter Worker-Benutzer: Läuft der Worker mit einem normalen Benutzer-Konto und die Person meldet sich ab oder ändert ihr Passwort, bricht der Dienst ab. JTL empfiehlt laut Dokumentation einen separaten Benutzer nur für den Worker, mit deaktiviertem Passwort-Ablauf.
• →Zombie-Client-Prozesse bei Shop- oder eBay-Abgleich: Ein einzelner Abgleich-Prozess (JTL-Worker-Client.exe) kann sich aufhängen, ohne dass der Worker-Dienst das bemerkt. Der Status zeigt ‚läuft‘, aber neue Abgleiche starten nicht mehr. Ursache ist meist ein Timeout bei der Datenbankverbindung oder eine Shop-API die nicht antwortet.
• →Fehlende Schreibrechte auf den AppData-Ordner: Der JTL Worker 2.0 speichert seine Zugangsdaten in einer XML-Datei im AppData-Ordner des Windows-Benutzers. Fehlen dort die Schreibrechte, kann der Worker seine Konfiguration nicht lesen und startet nicht.

Der Worker selbst ist selten das Problem. Es liegt fast immer an der Umgebung: Windows-Benutzer, Dienst-Konfiguration, Datenbankbereitschaft beim Boot. Wer diese drei Punkte einmal sauber einrichtet, hat dauerhaft Ruhe.

Die Symptome klingen ähnlich, haben aber unterschiedliche Ursachen und brauchen unterschiedliche Ansätze. Hier die Unterscheidung aus der Praxis:

1

Worker startet nach Neustart nicht

Der Dienst steht in der Windows-Diensteverwaltung auf ‚Gestoppt‘ oder zeigt direkt beim Hochfahren einen Fehler. Ursache ist fast immer ein falsches Passwort im Dienst-Konto, ein zu früher Startzeitpunkt oder ein fehlendes Benutzer-Konto.

Die Prüfung ist schnell erledigt: Dienstverwaltung öffnen (services.msc), Worker-Dienst suchen, Eigenschaften > Anmelden > Passwort neu eingeben. Danach Starttyp auf ‚Automatisch (verzögert)‘ setzen. Laut JTL-Guide ist die Schreibweise des Windows-Benutzernamens kritisch: ‚COMPUTERNAME\\Benutzername‘ ist Pflichtformat.

2

Worker läuft, Abgleich findet aber nicht statt

Der Dienst ist aktiv, die Wawi zeigt grünen Status, aber im Shop kommen keine Bestellungen an und Bestände werden nicht synchronisiert. Hier ist ein Client-Prozess (JTL-Worker-Client.exe) hängen geblieben. Im Task-Manager erkennbar an mehreren Worker-Client-Prozessen mit langer Laufzeit und 0% CPU.

Ein Händler im JTL-Forum beschrieb das so: ‚Der Shopabgleich bleibt bei Initial: 1. Aufruf — [0,00%][0%] stecken, seit Stunden. Der Dienst läuft laut Windows, aber passiert tut nichts.‘ Die Lösung: gezielt den einzelnen hängenden Client-Prozess beenden, nicht den ganzen Dienst neu starten. So stößt der Worker den Prozess neu an, ohne dass andere laufende Abgleiche abbrechen.

Keine manuellen Eingriffe mehr

Ein Händler (anonymisiert, Bereich Haushaltsartikel) kam zu uns, weil er den Worker jeden Morgen manuell prüfte und mehrmals pro Woche neu startete. Nach Neueinrichtung mit dediziertem Worker-Benutzer, verzögertem Starttyp und Monitoring-Routine lief der Dienst vier Wochen ohne einen einzigen manuellen Eingriff. Wir haben das Setup in einem einzelnen Termin umgebaut.

Bestellungen landen zuverlässig in der Wawi

Bei einem zweiten Händler (anonymisiert, Sportartikel-Bereich) kamen Bestellungen aus dem Shop zeitweise verzögert oder gar nicht an. Ursache: ein regelmäßig hängender eBay-Abgleich der den ganzen Worker blockierte. Nach dem Entzerren der Abgleich-Intervalle und einer Watchdog-Lösung auf Basis der Worker.tStatus-Tabelle lief die Synchronisierung stabil. Wir setzen diese SQL-basierte Überwachung bei jedem Händler ein, der mehr als einen aktiven Verkaufskanal betreibt.

Die folgende Reihenfolge hat sich in unserer Praxis bewährt. Schritt 1 bis 3 sind in den meisten Umgebungen schnell abgehakt und lösen den Großteil der Worker-Probleme.

„Öffne die Windows-Dienstverwaltung (services.msc) und suche den JTL-Worker-Dienst. Steht er auf ‚Gestoppt‘? Dann in die Windows-Ereignisanzeige unter Windows-Protokolle > Anwendung und nach Einträgen mit Quelle ‚JTL-Worker‘ suchen. Der häufigste Fehler ist ein Anmelde-Fehler wegen falschem Passwort, erkennbar an Event-ID 7038 oder ähnlichen Dienst-Fehlern. Laut JTL-Guide schreibt der Worker vor jeder Aktion ein Log-Event. Pausen über 8 bis 10 Minuten ohne neuen Eintrag deuten auf einen hängenden Prozess hin.“

„In der Dienstverwaltung Eigenschaften > Anmelden des Worker-Dienstes öffnen und das aktuelle Windows-Passwort des Dienst-Kontos neu eintragen. Achte auf das exakte Format: COMPUTERNAME\\Benutzername (ohne Domain bei lokalen Konten). Wenn es noch keinen dedizierten Worker-Benutzer gibt, lege jetzt einen an: in JTL-Wawi unter Admin > Benutzer/Rechte. Die Option ‚Benutzer muss Passwort ändern‘ muss deaktiviert sein. Details zur Einrichtung in der JTL-Dokumentation zum Worker als Windows-Dienst.“

„In den Eigenschaften des Worker-Dienstes den Starttyp von ‚Automatisch‘ auf ‚Automatisch (verzögert starten)‘ umstellen. Kleiner Unterschied, großer Effekt: Der Worker bekommt Zeit, bis die SQL-Datenbank vollständig hochgefahren ist. Genau daran scheitert der sofortige Start in vielen Umgebungen. Danach den Dienst einmal manuell starten und das System neu hochfahren, um den Effekt zu prüfen.“

„Wenn der Dienst läuft, aber kein Abgleich stattfindet: Task-Manager > Details öffnen und nach ‚JTL-Worker-Client.exe‘ filtern. Mehrere Instanzen mit langer Laufzeit und 0% CPU sind ein klares Zeichen für Zombie-Prozesse. Beende gezielt nur diese auffälligen Instanzen, nicht den ganzen Worker-Dienst. Der Worker startet den Prozess danach automatisch neu. Für die automatische Überwachung empfiehlt das JTL-Forum eine Abfrage der Tabelle Worker.tStatus in der Wawi-Datenbank auf Zeitstempel-Lücken über 8 Minuten.“

„Wer mehr als einen Verkaufskanal betreibt, sollte den Worker nicht nur manuell im Blick behalten. Bewährt hat sich eine Prüfung der Worker.tStatus-Tabelle alle zwei Minuten: Ist der letzte Zeitstempel älter als 8 bis 10 Minuten, wird ein Alarm ausgelöst oder der Dienst automatisch neu gestartet. Für Händler ohne eigene IT-Abteilung übernehmen wir das Monitoring komplett. Melde dich über unser Kontaktformular, wenn wir das für dich einrichten sollen.“

Wenn der Worker läuft, aber der Abgleich fehlschlägt