-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Process occasionally stuck - still occuring #122
Comments
I confirm the issue, last week here too. |
bestätige ebenfalls das Problem JSController 5.0.12 |
Adapter Version 4.2.0 nehme ich an - oder? |
@MarioSander Bitte um ein vollständiges debug log. Bitte unbedingt auch die vom js-controller stammenden "adapter started" / "adapter terminated" Meldungen includieren. Und sofern ein erfolgreicher Lauf vor dem Hänger existiert bitte auch das Log (incl. start/stop) dieses Laufs drinnen lassen. Danke P.S. Da ich keine Oilfox und damit auch keine Zugangsdaten zum Testen ahbe kann ich leide nur im Trüben suchen... |
kommt, ist auf debug gestellt, hatte letzte Nacht auch wieder ein Haenger vom Task, das kommt nur alle paar Tage, aber sonst holt er taeglich die Daten. Mit dem workaround-script killt er den process ja. |
Hier das Debug-Log, alle Emails und Passwoerter und token ersetzt: ` |
so, gestern wieder ein Haenger, das ganze passiert wohl, dass der Adapter die Daten nach dem ersten abholen nochmal abholt, und sich dann weghaengt, im Log sieht man das deutlich(ich habe nix gefiltert, nur Email/Pw geaendert): 20:00:00:25 - Adapter startet erneut, soll er eigentlich nicht Spaeter startet mein scheduled javascript und checkt ob der process noch laeuft, und ja, er ist da: 20:53:00.027 - oilfox process mit PID 10690 gefunden und gekillt 20:53:01.540 - Adapter oilfox terminating... da beendet er sich dann, weil der process gekillt wurde. Hier das logfile: ` 2024-01-10 20:53:00.021 - �[32minfo�[39m: javascript.0 (597) script.js.common.Schalter.oilfox: exec: ps -C io.oilfox.0 -o pid= 2024-01-10 20:53:01.027 - �[33mwarn�[39m: javascript.0 (597) script.js.common.Schalter.oilfox: Trying to kill oilfox process with PID: 10690 2024-01-10 20:53:01.038 - �[32minfo�[39m: javascript.0 (597) script.js.common.Schalter.oilfox: exec: kill 10690 2024-01-10 20:53:01.540 - �[32minfo�[39m: oilfox.0 (10690) terminating ` |
Soda - heut hab ich mal Zeit in dieses Issue gesteckt: a) der Default cron */59 * * * * ist grob gesagt unsinnig. Dieser ewirkt nämlcih dass ein Job zur Minute 59 UND zur Minute 0 erfolgt - was definitiv Blödsinn ist. (Ich hab aber auch erst auf cron Gure gelernt was /x wirklich bedeutet. Ergebnis siehe Screenshot Damit ist die doppelasuführung mal geklärt. Ob das das Händen bwrikt - keine Ahnung b) Der Oilfox bekommt noch einen Holzhammerwatchdog verpasst (-> work in progress). Wenn der Adapter länger als 60 Sekunden läuft dann stoppt er sich in Zukunft selbst,. |
Stimmt, ich weiss auch nicht, was "alle n 59 Minuten" soll.. habe es mal auf "bestimmte Minuten 34" also 34 * * * * geaendert und beobachte mal weiter.. |
Da ich oilfox HW nicht kenne eine Zusatzfrage: Abfrage 1x Stunde irgendwann innerhalb der Stunde wäre als default OK? |
ja, absolut, die Hardware wacht einmal am Tag auf, misst den Tank, sendet die Daten und geht wieder schlafen. |
Also ich weiß nicht warum, aber seit dem ich mein iobroker system vom Raspi auf nen Lenovo Think Centre M910q und Proxmox umgezogen hab, läuft die ganze Sache mit dem Oilfox einwandfrei ohne Datenabbrüche. |
should be fixed with 4.2.1 Please note or open a new issue if still occuring |
Describe the bug
This is a re-opening of the ticket: #110 (comment)
as the issue still occurs in my installation on v4.2.0. The cadence of the problem seems to be mostly occuring once a day on different times. Seldomly either twice a day or none. I can't tell any pattern from it, so it appears random.
Sometimes I observe that no new data is obtained for a couple of days. While investigating it I found out that, in this situation host.iobroker is logging:
After killing the process via SSH, the adapter is correctly polling the data according to the schedule.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
The process must not freeze and the data must be obtained reliably
Screenshots & Logfiles
If applicable, add screenshots and logfiles to help explain your problem.
Versions:
Additional context
This is a re-opening
The text was updated successfully, but these errors were encountered: