IPS Dienst stürzt ab

IP-Symcon
1

Komisch ich habe nun eine Instabilität. IPS beendet sich unerwartet. Meine Version und System sind: IP-Symcon 4.4, Windows x86, 10.01.2018, 0f19800dcb96

Was hat sich geändert?

  • Update auf die u.g. Version
  • Verstärkte Nutzung eigenes PHP Modul (FTS)
  • Bisherigen Splitter/Registervariable für Eno-Gateway deaktiviert

Logs:

  • Es wird kein minidump geschrieben?
  • Im Standardlogfile ist nichts

Können PHP Module das System killen (Speicherprobleme)

Der IPS Service belegt gerade nur 50MB und CPU langweilt sich.

2

Ja, du kannst über PHP-Module den Dienst killen. Da du über Skripte ziemlich alles im System machen kannst, ist es sicherlich möglich, den Dienst in einen Zustand zu führen, in dem er abstürzt.

Wie häufig tritt der Absturz denn ein? Hast du die Möglichkeit hier ein wenig zu testen? Insbesondere interessant wäre es, ob der Dienst sich auch ohne dein Modul beendet.

3

Also aus der letzten Zeit kann ich berichten:

Vor dem update auf die letzte Version. War aber schon eine 4.4 hatte ich mal einen Absturz im Monat.

Jetzt mit der aktuellen Version und den PHP Modulen war in 2 Tagen zweimal das System weg. Die Module machen keine Raketenwissenschaft also Daten aus einem Enocean Gateway auswerten und Variablen setzen und Daten weitergeben. Mehr nicht.

Kann ich noch irgendwas als Trace mitlaufen lassen was mich der Sache näher bringen würde?

4

Hast du mal geschaut, ob während der Laufzeit der Speicher ansteigt? (Direkt nach dem Start sind 50 MB ok, es könnte ja nach und nach mehr werden)

paresy

5

Schaue ich mal. Ich habe sowieso merkwürdige Phänomene aktuell.

  • [ul]
    [li]Alexa Connect funktioniert öfter nicht mehr. Connect Instanz kurz aus machen bringt IPS zum Absturz.
    [/li][li]Auch ein Runterfahren von IPS wird in den seltensten Fällen, wenn IPS mal länger läuft, erfolgreich erledigt.
    [/li][li]Und die Enocean Instanz zum FWG stirbt irgendwann weg. Kein Keep Alive sondern nur ein uns ausschalten der Instanz hilft zum reaktivieren.
    [/li][/ul]
6

Hast du mal im Meldungsfenster oder den PHP Informationen geschaut, ob dort alles OK ist und keine Fehlermeldungen auftreten?

paresy

7

Im Meldungsfenster ist nichts unerwartetes erkennbar. Weder beim Absturz (Es wird kein Mini-Dump gemacht!) noch wenn die FGW SST aussteigt.

Ich habe einen Punkt noch erkannt zum beheben. Ich hatte im Log komische Darstellungen. Nach 00:xx kam irgendwann eine Uhrzeit 12:xx und dann wieder 00:xx wie einfach dazwischen geschrieben.

Ich habe aktuell den Verdacht das die Pufferbatterie wegen der Uhr leer ist. Die Uhrzeit verstellt sich im Betrieb. Hätte erwartet das dies im laufenden Betrieb nicht passiert. Hatte erst den NTP Dienst in verdacht und dieses nun deaktiviert. Und dennoch hatte ich heute morgen um 7 Uhr wieder eine Zeit 12 Uhr. komischerweise die Minuten stimmten. Komisch

Keine Ahnung ob das verstellen der Zeit dann IPS durcheinander bringt?

8

Hallo zusammen,

mein Symcon stürzt auch seit einigen Wochen unregelmäßig ab. Ich hatte schon ein Ubuntu im Verdacht und habe es am Wochenende neu aufgesetzt. Leider war dies vergebens.

Meine Symcon-Umgebung ist:

[ul]
[li]OS: Ubuntu LTS 16.04.4
[/li][li]IP-Symcon 4.4, Ubuntu, 19.02.2018, 36a7b6fcaa27
[/li][/ul]

Nach dem letzten Absturz von heute morgen ist der letzten Eintrag im Log

05.03.2018 08:15:06 | 44040 | ERROR | TimerPool | Z-Wave Gateway (KeepAlive): Zeitüberschreitung beim Warten auf Bestätigung
05.03.2018 08:15:39 | 45229 | WARNING | ScriptEngine | Ergebnis für Ergebnis 45229
<br />
<b>Warning</b>: Waiting for script result timed out in <b>-</b> on line <b>1</b><br />

Suche ich nach einem Element mit der ID 45229 wird jedoch nichts gefunden.

Was kann ich nun noch tun, um dem Problem weiter auf die Spur zu kommen?

Danke für eure Unterstützung.

Viele Grüße,
bition

9

Am besten dies hier mal ausprobieren: Debugging für Experten (Raspberry Pi, Linux)

paresy

10

Also das Zeit Problem war wirklich die Batterie auf dem Mainboard.

Ansonsten konnte ich noch keine Analyse wegen Windows Update machen.

Hab nur einmal beobachtet das der Dienst von 55 MB auf 105 MB angewachsen ist. Meine am nächsten morgen war er wieder bei 55 MB. Kann das am 0 Uhr aufräumen liegen?

11

Es wäre möglich, dass es sich bei der ID 45229 um ein Event handelt, welches sich nach einmaliger Ausführung selbst löscht. Der Code dazu sieht wie folgt aus:

$event = IPS_GetEvent(12345);
$parameter = array('BITION' => true, 'BIT_eventAction' => 210, 'BIT_eventVariableId' => $event['TriggerVariableID'], 'BIT_eventAppendix' => '');
IPS_RunScriptWaitEx(67890, $parameter);
IPS_DeleteEvent(12345);

Eventuell hilft dies bei der Fehlerbetrachtung weiter?

12

Danke paresy für deine schnelle Antwort.
Debugger läuft. Ich melde mich dann wieder nach dem nächsten Absturz.

13

Hallo zusammen,

ich konnte noch nicht mittels der Debugging-Methode das aktuelle Problem ermitteln, da der Absturz nicht so einfach debuggbar ist. Heute war ich einmal „live“ bei einem Absturz dabei, wobei dies eher ein Prozess als ein einzelner Fehler ist.

Bevor Symcon sich unerwartet beendet, wird der komplette PC unbedienbar. Die CPU-Last liegt bei fast 100% und die RAM sind mit 100% gefüllt. Das System reagiert weder auf Maus- noch auf Tastatur-Eingaben. Daher konnte ich leider auch nicht mehr in der Konsole sehen, was aktuell passiert, da auch der Bildschirm einfiert.

Kann ich irgendwie nachvollziehen, ob Symcon die Belastung verursacht und falls ja, woran es liegt?

Danke für den Support.

Viele Grüße,
bition

14

Ich konnte nun mit

htop

nachvollziehen, wodurch der ganze RAM belegt wird. Es handelt sich tatsächlich um den Dienst

/usr/bin/symcon

, welcher mit jedem Trigger und jeder Skriptausführung ansteigt und den Speicherplatz auch nicht wieder freigibt.

Ich konnte in den letzten 30 Minuten durch das Ausführen von einigen Events und Skripten den Dienst bereits dazu bringen knapp 3,5 GB RAM zu belegen, welche auch nicht wieder freigeben werden. Verbunden mit weiteren Diensten sind das 100% meines 4 GB Arbeitsspeichers. Das Verhalten und der Absturz von Symcon kann somit eindeutig reproduziert werden.

Können wir dieses Problem irgendwie gemeinsam lösen?

15

Kannst du das Problem noch einmal nachstellen, wenn wir uns es gemeinsam per TeamViewer ansehen?
Kannst du uns Morgen sonst einfach mal im Office dazu anrufen?

paresy

16

Hallo paresy,

sehr gerne können wir das Verhalten morgen auch noch einmal zusammen nachstellen. Ich befürchte aber, dass ich erst gegen 18:00 Uhr wieder an meinem Server sitzen kann.

Gerne rufe ich dich aber auch im Laufe des Tages mal an und wir sprechen noch einmal persönlich über das Verhalten.