Neu Worker Probleme mit nssm/Dienst seit Update auf 1.4.28.1

[hula1499]

Hallo,

seit dem Update auf 1.4.28.1 hab ich ein - für mich - unlösbares Problem mit dem Worker-Dienst und spiel mich da jetzt schon seit Stunden damit herum.

https://ebakery.de/jtl-wawi-worker-als-dienst-starten/
auch schon mit 1.3 verwendet, lief alles perfekt, auch mit der letzten stable WaWi Version (1.4.27.x), aber jetzt mit 1.4.28.1 spinnt das nur herum.

Rufe ich im cmd auf:
JTL-wawi.exe WORKER xyz name pass eazybusiness
startet der Worker, holt ab, gleicht ab, alles gut - keinerlei Fehlermeldung da drinnen, nix.

Läuft jedoch der Dienst, hab ich nur Fehler und es findet definitiv kein Abgleich statt. Fehlermeldungen und ähnliches gibts ja nicht.

Schau ich ins Protokoll am Sever:
Service JTL-WorkerHHS2 action for exit code 0 is Restart. Attempting to restart C:\Program Files (x86)\JTL-Software\JTL-Wawi.exe.
Killing process tree of process 12800 for service JTL-WorkerHHS2 with exit code 0
Program C:\Program Files (x86)\JTL-Software\JTL-Wawi.exe for service JTL-WorkerHHS2 exited with return code 0.
Killing PID 12800 in process tree of PID 12800 because service JTL-WorkerHHS2 is stopping.

Dann startet der Dienst wieder neu und das geht so im Sekundenryhtmus weiter.



Es laufen 2 Dienste, für 2 Mandaten mit unterschiedlichem Account/PW.

Für die 1.4.28.1 musste ja FRamwork upgedated werden (danke JTL dass das irgendwo steht als Voraussetzung...) spielt das da irgendwie rein?
Ich hab die Dienste bereits XX mal deaktiviert, gelöscht, neu erstellt, server X mal neu gestartet....

Irgendwer ne Idee?

 

[css-umsetzung]

Du lässt den Worker zweimal laufen obwohl es nur eine Datenbank ist?
Eazybusiness/mandant_1

Das wäre falsch.

 

[hula1499]

2 worker für 2 unterschiedliche Datenbanken.

JTL-wawi.exe WORKER HHS name pass eazybusiness
JTL-wawi.exe WORKER Name2 name1 pass1 eazybusiness

 

[css-umsetzung]

Ok, das hörte sich grad anders an
Nun bekomm ich Panik, ich wollte das auf meinem Server auch updaten, da laufen drei Worker

 

[hula1499]

Die Zugangsdaten sind 100% richtig, hab sogar in beiden WaWis die Zugangsdaten geändert (waren vorher gleicher user/pw) -> auch nicht geholfen.

Kann das irgendwie mit dem .NET Framework 4.7.2 update zu tun haben? Win Update gabs keines, sonst auch keine Änderungen/Updates.

Es wird mir jetzt irgendein Hinweis in der WaWi angezeigt von wegen es gibt angeblich ein SQL Sever SP, Win Update zeigt kein SQL SP an...

Wie gesagt, ruf ich den befehl im CMD auf, kommt das Worker Fenster und macht alle Abgleiche fertig...

 

[css-umsetzung]

ich trau mich nicht das bei mir upzudaten.
eigentlich sollte das über nssm keinen unterschied machen.

 

[Xantiva]

Hast Du beide gleichzeitig laufen? Oder zum Testen erst mal nur einen gestartet?
Was passiert, wenn Du zwei Eingabefenster parallel öffnest und versucht beide Befehle quasi gleichzeitig auf der Konsole auszuführen?

 

[hula1499]

Morgen,

hab auch versucht, nur einen Worker-Dienst zu starten -> ebenfalls Fehler (bleibt immer auf FEHLER , um hier einfach einen Anzeigebug auszuschliessen, hab ich eine Testbestellung gemacht und geschaut, ob sie in die WaWi kommt -> negativ).
Hatte vorher bei beiden die gleichen Logins, diese auch schon geändert auf unterschiedliche Logindaten (User+PW).

Habe jetzt via CMD beide Worker aufgerufen über Nacht, Bestellungen kommen in die WaWi rein.

 

[Xantiva]

Demnach hat das nichts mit dem Parallelbetrieb zu tun, wenn er schon bei nur einem Dienst passiert. Ich sehe auf Anhieb auch nicht, was sich mit 4.7.2 geändert haben könnte und Probleme bereitet: https://docs.microsoft.com/de-de/dotnet/framework/whats-new/#v472

Du könntest das Logging der Wawi mal hoch setzen / aktivieren. Vielleicht kann man da Hinweise finden?

 

[hula1499]

Ich glaub in dem Fall nichtmal, dass es direkt an der WaWi liegt sondern die Kombi mit nssm/den Diensten (ruf ich den Worker via CMD auf, beide laufen paralell, funktioniert ja alles perfekt).
Die sind richtig (waren auch unverändert) und wurden bereits XXmal neu erstellt, ein Eingabefehler in den Zugangsdaten kann ich zu 100% ausschliessen.

Auch versteh ich die Fehlermeldung/Info beim Einloggen in der WaWi wegen SQL und ServicePack nicht so ganz, es gibt keines.

Logs mal für alles aktiviert was ich gefunden hab, aber dieses dienst stoppen/neustarten befürcht ich kommt jetzt eher von Win Sever 2016.

 

[hula1499]

Admin Global -> Debug -> alles aktiviert.
Worker Dienst gestartet, 30 Mins. gewartet (steht auf 120 sek. stand.) -> nix in den Logfiles.

Server Ergeignisanzeige:
Service JTL-WorkerHHS received STOP control, which will be handled.
Killing process C:\Program Files (x86)\JTL-Software\ JTL-Wawi.exe because service JTL-WorkerHHS is stopping.
Killing process tree of process 13116 for service JTL-WorkerHHS with exit code 0
Killing PID 13116 in process tree of PID 13116 because service JTL-WorkerHHS is stopping.

 

[Xantiva]

Hm,

"Service JTL-WorkerHHS received STOP control, which will be handled"

ich nehme an, "JTL-WorkerHHS" ist einer Deiner beiden Dienste? Der Dienst bekommt die Anforderung anzuhalten? Das sorgt dann dafür, dass die Prozesse der Wawi angehalten werden. Wie Du schon schreibst - das liest sich nicht so, als wenn die Wawi einen Fehler hätte, sondern irgend was den Dienst anhält bzw. oben einen Restart anfordert.

Hast Du mal versucht die Ausgabe von dem nssm zu loggen? https://nssm.cc/usage => I/O redirection => AppStdout / AppStderr

 

[hula1499]

Guten Morgen,

leider steht auch hier im Log quasi nichts

Connected to ROOT\CIMV2 WMI namespace
ist das einzige, das ich in das Log von nssm reinbekomme, wobei das log von AppStderr leer ist.

Nachtrag:
Hatte ja den Worker via CMD aufgerufen und laufen. Nach dem Lesen des Hinweises hier, das Fenster geschlossen, dieses appstdout/appstderr gemacht und Dienst wieder gestartet.
Lustigerweise bleibt die Anzeige des Workers nach diesem appstdaut/appstderr weiterhin auf grün (mit gestartetem Dienst), Abholung findet jedoch keine statt (testbestellung gemacht).
Im Ergebnisprotokoll von Windows, wird der Dienst weiter gekillt, neu gestartet etc.

 

[Rico Giesler]

Mach dazu bitte mal ein Ticket auf. Eventuell haben die Kollegen eine Idee woran das liegen könnte.

 

[css-umsetzung]

Ich hab mich mal getraut, auf meinem Server mit nssm läuft weiterhin alles normal wie es scheint.
Ist aber ein Windows 2012 Server

 

[SebiW]

Ich hänge mich hier mal als Beobachter dran, wir haben quasi das gleiche Szenario, wenn auch mit nur einem Worker. Ich warte jetzt auch erstmal mit dem Update auf die 1.4.28

@hula1499 für Feedback zu Fehlerbehebung etc hier im Thread wäre auch ich sehr dankbar.

 

[hula1499]

Ja, wenn ich eine Lösung hab, dann poste ich sie hier natürlich.

Bis dato leider nichts, Ticket vom Freitag hat leider auch noch kein Ergebnis gebracht, jetzt laufen die Worker halt "normal" - ohne Dienst, was natürlich für einen kurzen Zeitraum kein Problem ist.

 

[hula1499]

Wie eh schon erwartet, hier die Antwort vom Support:

wir empfehlen es Grundsätzlich nicht den Worker als Dienst laufen zu lassen. Auch ist dieser aktuell dafür nicht ausgelegt. Sollte es dort (wie in Ihrem Fall) zu Fehlern kommen und der "normale" Worker funktioniert dann müssen Sie diesen als Programm starten.

Ich werd mich morgen weiter selbst damit herumspielen und eine Lösung suchen.

 

[SebiW]

Hi @hula1499
konntest Du das Problem lösen/eingrenzen?
Ich traue mich im Moment nicht wirklich ran weil ich das Szenario eines nicht sauber überwachten Workers echt unattraktiv finde.

 

[hula1499]

Update gerade auf die 1.4.29.1 und werde das Thema danach nochmal angehen.

Jetzt laufen sie halt "normal" (also der komische JTL Standartweg) mit dem Workerüberwachungsscript vom Andreas, damit zumind. ne Mail kommt, wenn einer der Workers hängt.