Symcon Dienst unter Windows stürzt ab, TimerPool Meldungen im Log

IP-Symcon 4.x/5.x/6.x
1

Heute Nacht ist bei mir der Dienst abgestürzt und folgende letzte Einträge im Log fallen auf:

02.04.2023 03:43:22 | 00000 | ERROR   | TimerPool            | Konnte Thread für Timer 781 nicht erstellen: resource unavailable try again: resource unavailable try again
02.04.2023 03:43:24 | 00000 | ERROR   | TimerPool            | Konnte Thread für Timer 148 nicht erstellen: resource unavailable try again: resource unavailable try again
02.04.2023 03:43:24 | 00000 | ERROR   | TimerPool            | Konnte Thread für Timer 491 nicht erstellen: resource unavailable try again: resource unavailable try again
02.04.2023 03:43:30 | 00000 | ERROR   | TimerPool            | Konnte Thread für Timer 332 nicht erstellen: resource unavailable try again: resource unavailable try again

Wie kann ich dem Problem auf den Grund gehen?

2

Klingt nach einem Deadlock. Fehlersuche wird eher schwierig - es sei denn du weißt, wie man es provozieren kann. Ich kann Morgen mal schauen, ob dein Gerät ggf. einen Crashlog hochgeladen hat.

paresy

3

Das wird dann wohl schwierig, diese Abstürze kommen (zum Glück) sehr selten vor. Gefühlt 3-4 mal im Jahr.

4

Es ist heute Nacht der Dienst nun relativ sang- und klanglos stecken geblieben. Letzter Hinweis im Log auch eher subtil:

05.04.2023 03:15:32 | 12974 | WARNING | ScriptEngine         | Result for Event 27477

Warning: Cannot create process as user. Error: 1455 in C:\ProgramData\Symcon\scripts\12974.ips.php on line 503

Warning: Cannot create process as user. Error: 1455 in C:\ProgramData\Symcon\scripts\12974.ips.php on line 503

An der Stelle wird mit IPS_ExecuteEx ein Prozess in der User Session erstellt. Es geht um mein Skript um bei einem Silex USB Host die Verbindung für ein Gerät zurückzusetzen.

5

Nach oberflächlicher Recherche könnten die Fehler etwas mit der Größer der Swapfile zu tun haben. Diese ist auf „automatisch“ eingestellt und im Ressourcenmonitor deutet nichts auf einen Speichermangel hin… na ja, ich mache mal das übliche und starte neu.

Dass der Dienst einfach stecken bleibt ist natürlich tendenziell noch unerfreulicher weil man außer über einen externen Watchdog dann gar nicht darauf reagieren kann. Ich habe jetzt für ein unerwartetes Beenden wenigstens eingetragen, dass der Dienst neu gestartet wird. Aber wenn der Dienst einfach nichts mehr tut, dann wird das auch nichts nützen.

6

Wieviel MB verbraucht die ips.exe denn? Evtl. Gibt es ein Speicherleck? Hast du den ggf. mal mitgeloggt?

paresy

7

Ich achte mal auf den Speicherbedarf des Dienstes.

1 „Gefällt mir“
8

Also aktuell ca 400 MB Arbeitsspeicher, Tendenz langsam steigend.

1 „Gefällt mir“
9

Steigt heute langsamer, also ich finde es so nicht bedenklich. Beobachte weiter und melde mich in einigen Tagen

10

Also jetzt 416… klar, wenn es immer so weiter geht ist es theoretisch irgendwann ein Problem, aber alarmierend finde ich es jetzt nicht.

11

Wobei, wenn du sagst es passiert 3-4 mal im Jahr und du lange Strecken nicht neu startest, könnte es evtl. daran liegen.

paresy

12

Weitere Beobachtung, gestern habe ich einmal den Dienst neu gestartet um einen neuen Watchdog zu testen und dabei kam er zwar wieder hoch, aber es war kein Zugriff aufs Webfront oder Konsole möglich. Ich konnte auch keine auffälligen Meldungen im Log dazu finden. Ansonsten schien der Dienst zu funktionieren, aber es gab keine Möglichkeit mehr, sich über HTTP zu verbinden.