Mysteriöser Absturz

Hallo,

dieser Absturz ist jetzt schon zweimal vorgekommen. Mein HMS Melder hängt überdems an der USB-FHZ, und warum der Designer-Client (192.168.1.30) auch disconnected wurde, bleibt auch ein Mysterium:

Ausserdem stelle ich ein RRDTool Timeout fest ??? seufz Fragen, Fragen, Fragen, und kein Ende in Sicht ! :rolleyes:

6/28/2006 15:01:27.128 | DEBUG | ExecuteThread ID: 3484 | Executed, Ret: 1, Successful:True
6/28/2006 15:01:28.941 | DEBUG | VariableManager | Variable: KID1_FHT_ACTUAL_VPOS (Float), Value: 0
6/28/2006 15:01:28.941 | DEBUG | ExecuteThread ID: 856 | Executing Script: KID1_HMI.ips.php ~ Sender: Variable: KID1_FHT_ACTUAL_VPOS, Trigger: OnUpdate
6/28/2006 15:01:28.951 | DEBUG | VariableManager | Variable: KID1_HMI_TRIGGER (String), Value: KID1_FHT_ACTUAL_VPOS
6/28/2006 15:01:28.951 | DEBUG | VariableManager | Variable: KID1_HMI_LEVEL_HEATER (Integer), Value: 1
6/28/2006 15:01:28.951 | DEBUG | ExecuteThread ID: 856 | Execution Result:

6/28/2006 15:01:28.951 | DEBUG | ExecuteThread ID: 856 | Executed, Ret: 1, Successful:True
6/28/2006 15:01:31.665 | DEBUG | RRDTool | Command Timeout # Command: graph /IP-Symcon/graphs/masbed.png --start -432000 --end -300 --width 420 --height 180 --color CANVAS#ffffff --color BACK#ffffff --color FONT#000000 --color MGRID#80C080 --color GRID#808020 --color FRAME#808080 --color ARROW#FFFFFF --color SHADEA#404040 --color SHADEB#404040 --lower-limit 5 --upper-limit 35 --rigid DEF:actual=/IP-Symcon/graphs/masbed.rrd:actual:AVERAGE DEF:target=/IP-Symcon/graphs/masbed.rrd:target:AVERAGE LINE2:actual#00af00:actual_temperature LINE2:target#ef8e00:target_temperature
6/28/2006 15:01:31.665 | DEBUG | RRDTool | Send: graph /IP-Symcon/graphs/kid3.png --start -432000 --end -300 --width 420 --height 180 --color CANVAS#ffffff --color BACK#ffffff --color FONT#000000 --color MGRID#80C080 --color GRID#808020 --color FRAME#808080 --color ARROW#FFFFFF --color SHADEA#404040 --color SHADEB#404040 --lower-limit 5 --upper-limit 35 --rigid DEF:actual=/IP-Symcon/graphs/kid3.rrd:actual:AVERAGE DEF:target=/IP-Symcon/graphs/kid3.rrd:target:AVERAGE LINE2:actual#00af00:actual_temperature LINE2:target#ef8e00:target_temperature
6/28/2006 15:03:46.699 | MESSAGE | Designer Interface | Client Disconnected [192.168.1.39]
6/28/2006 15:04:17.83 | MESSAGE | Designer Interface | Client Connected [192.168.1.39]
6/28/2006 15:05:30.458 | DEBUG | VariableManager | Variable: BATH1_HMS_GAS_DETECT (Boolean), Value: False
6/28/2006 15:06:05.479 | DEBUG | VariableManager | Variable: CENTHEAT_HMS_TEMP (Float), Value: 21.8999996185303
6/28/2006 15:11:26.490 | DEBUG | VariableManager | Variable: CENTHEAT_HMS_TEMP (Float), Value: 21.8999996185303
6/28/2006 15:16:47.502 | DEBUG | VariableManager | Variable: CENTHEAT_HMS_TEMP (Float), Value: 21.8999996185303
6/28/2006 15:22:08.533 | DEBUG | VariableManager | Variable: CENTHEAT_HMS_TEMP (Float), Value: 21.8999996185303
6/28/2006 15:27:29.555 | DEBUG | VariableManager | Variable: CENTHEAT_HMS_TEMP (Float), Value: 21.8999996185303
6/28/2006 15:32:50.567 | DEBUG | VariableManager | Variable: CENTHEAT_HMS_TEMP (Float), Value: 21.8999996185303
6/28/2006 15:34:42.47 | DEBUG | VariableManager | Variable: BATH1_HMS_GAS_DETECT (Boolean), Value: False
6/28/2006 15:38:11.618 | DEBUG | VariableManager | Variable: CENTHEAT_HMS_TEMP (Float), Value: 21.8999996185303
6/28/2006 15:43:32.610 | DEBUG | VariableManager | Variable: CENTHEAT_HMS_TEMP (Float), Value: 21.8999996185303
6/28/2006 15:48:53.651 | DEBUG | VariableManager | Variable: CENTHEAT_HMS_TEMP (Float), Value: 21.8999996185303
6/28/2006 15:54:14.663 | DEBUG | VariableManager | Variable: CENTHEAT_HMS_TEMP (Float), Value: 21.8999996185303
6/28/2006 15:59:35.675 | DEBUG | VariableManager | Variable: CENTHEAT_HMS_TEMP (Float), Value: 21.8999996185303
6/28/2006 16:03:52.243 | DEBUG | VariableManager | Variable: BATH1_HMS_GAS_DETECT (Boolean), Value: False
6/28/2006 16:04:56.666 | DEBUG | VariableManager | Variable: CENTHEAT_HMS_TEMP (Float), Value: 21.8999996185303
6/28/2006 16:10:17.648 | DEBUG | VariableManager | Variable: CENTHEAT_HMS_TEMP (Float), Value: 21.8999996185303
6/28/2006 16:15:38.679 | DEBUG | VariableManager | Variable: CENTHEAT_HMS_TEMP (Float), Value: 21.8999996185303
6/28/2006 16:20:59.671 | DEBUG | VariableManager | Variable: CENTHEAT_HMS_TEMP (Float), Value: 21.8999996185303
6/28/2006 16:26:20.783 | DEBUG | VariableManager | Variable: CENTHEAT_HMS_TEMP (Float), Value: 22
6/28/2006 16:31:41.724 | DEBUG | VariableManager | Variable: CENTHEAT_HMS_TEMP (Float), Value: 22

und hier hing sich dann IPS mit „Blank Screen“ auf

PS für Paresy: Könnte man diesen blanken Screen nicht auf blau färben, so hätte man wieder den schönen „Win-98 Blue Screen“ :smiley:

mfG Franz

das kannst du selber konfigurieren: einfach blaue klarsichtfolie vor deinen screen kleben :wink:

…und gleich nochmal !

6/28/2006 18:03:58.239 | DEBUG | ExecuteThread ID: 1896 | Execution Result:
6/28/2006 18:03:58.239 | DEBUG | ExecuteThread ID: 1896 | Executed, Ret: 1, Successful:True
6/28/2006 18:04:00.91 | DEBUG | RRDTool | Command Timeout # Command: update /IP-Symcon/graphs/outtemp.rrd N:24.3
6/28/2006 18:04:00.91 | DEBUG | RRDTool | Send: graph /IP-Symcon/graphs/kitch.png --start -432000 --end -300 --width 420 --height 180 --color CANVAS#ffffff --color BACK#ffffff --color FONT#000000 --color MGRID#80C080 --color GRID#808020 --color FRAME#808080 --color ARROW#FFFFFF --color SHADEA#404040 --color SHADEB#404040 --lower-limit 5 --upper-limit 35 --rigid DEF:actual=/IP-Symcon/graphs/kitch.rrd:actual:AVERAGE DEF:target=/IP-Symcon/graphs/kitch.rrd:target:AVERAGE LINE2:actual#00af00:actual_temperature LINE2:target#ef8e00:target_temperature
6/28/2006 18:08:03.181 | DEBUG | VariableManager | Variable: CENTHEAT_HMS_TEMP (Float), Value: 22
6/28/2006 18:13:24.112 | DEBUG | VariableManager | Variable: CENTHEAT_HMS_TEMP (Float), Value: 22
6/28/2006 18:18:45.144 | DEBUG | VariableManager | Variable: CENTHEAT_HMS_TEMP (Float), Value: 22
6/28/2006 18:24:06.226 | DEBUG | VariableManager | Variable: CENTHEAT_HMS_TEMP (Float), Value: 22
6/28/2006 18:29:27.177 | DEBUG | VariableManager | Variable: CENTHEAT_HMS_TEMP (Float), Value: 22
6/28/2006 18:29:52.974 | DEBUG | VariableManager | Variable: BATH1_HMS_GAS_DETECT (Boolean), Value: False
6/28/2006 18:40:09.190 | DEBUG | VariableManager | Variable: CENTHEAT_HMS_TEMP (Float), Value: 22.1000003814697
6/28/2006 18:45:30.262 | DEBUG | VariableManager | Variable: CENTHEAT_HMS_TEMP (Float), Value: 22

so, habe nun festgestellt, dass der Übertäter das neue RRD_Modul ist. Irgendwie landen verschiedene RRD Befehle im Timeout! Doch jetzt kommts, IPS stürtz ab, aber RRDTool läuft weiter im Taskmanager und dann kann ich den Designer Port nicht mehr öffnen. Sogar ein Neustart meldet IPS mit „Couldn’t connect Designer on Port 3774“. Dann muss ich manuell RRDTool aus dem Taskmanager entfernen, und IPS neu starten !

Irgendwelche Ideen?

mfG Franz

Hallo Franz,

mische mich nur ungern ein (weil paresy hier nur helfen kann) - aber sei bitte so nett, und differenziere Deine Aussage genauer. Es gibt RRD zweimal:

  1. das IPS RRD Modul
  2. das RRDTool von Tobi

das letztere ist kein Modul, das koenntest Du aber aus dem TaskManager schiessen. Das erster kannst Du dagegen nicht im TaskManager killen.

Ich gehe auch weiterhin davon aus, dass RRDTool immer im Speicher bleibt, dass es als „Daemon“ laufen wird, solange noch vom IPS RRD Modul Befehle uebergeben werden sollen. Das waere also korrekt. Die Frage ist, ob eventuell hier die Queue Kommunikation im IPS RRD Modul ein Problem hat.

Leider kann ich es bei mir nicht nachvollziehen, das WIIPS mit genau dieser Variante (ich habe allerdings keinerlei Designer laufen) laeuft bei mir schon wieder seit 7 Tagen ohne Unterbrechnung und liefert normale Daten.

Auch die Memory Verwaltung seitens IPS scheint nunmehr in Ordnung zu sein, das ist also eine klare Linie.

Tja, leider kann ich nicht mehr zur Fehlersuche beitragen.

Gruss Torro

Hallo Torro,

ja, vielleicht habe ich mich ein wenig schlecht ausgedrückt:

Also, IPS hängt sich auf, nachdem die letzten Fehlermeldungen sichtbar vom IPS RRD Modul ausgehen. Meine Vermutung ist nun, dass man da nicht direkt so 15 Befehlszeilen reinschiessen sollte, da dann höchstwahrscheinlich das Queue überläuft. Was ist dennoch tue ! Ich bin gerade am Umbauen dieser Skripte, so dass die RRD_Execute aufrufe mehr verteilt werden, d.h, eben sequentiell, aber mit genügend Sicherheitsabstand. Nun, mit 15 Aufrufen ergibt das einen Sicherheitsabstand von 20 sekunden, was dann wiederum mein RRD update auf 300 Sekunden setzt, so wie ich es möchte !

Was ich vorhin meinte ist, dass irgendwie das RRDTool.exe, RRD Modul und der Designer in einem schrägen Verhältnis zueinander stehen ! Wie schons gesagt, IPS schmierte ab, dennoch konnte ich 2, sogar 3 Instanzen von RRDTool.exe im Taskmanager finden, obwohl IPS schon abgestürtzt war.
Wenn ich dann IPS neu startete, kriege ich von vorherein die Fehlermeldung „Couldn’t connect Designer to Port 3774“, und konnte auch von nirgendwo den Designer starten. Ich musste erst alle RRDTool.exe’s aus dem Taskmanager manuel schliessen, damit ich den Designer wieder starten konnte !
Irgendwie schräg !

mfG Franz

wieder Absturz !

nach 1 Stunde beriets !

man beachte das RRD Queue !

6/28/2006 21:37:44.732 | DEBUG | ExecuteThread ID: 1376 | Executing Script: WC_RST.ips.php ~ Sender: RunScript
6/28/2006 21:37:44.732 | DEBUG | ExecuteThread ID: 1376 | Execution Result:
6/28/2006 21:37:44.732 | DEBUG | ExecuteThread ID: 1376 | Executed, Ret: 1, Successful:True
6/28/2006 21:37:44.752 | DEBUG | ExecuteThread ID: 932 | Execution Result:
6/28/2006 21:37:44.752 | DEBUG | ExecuteThread ID: 932 | Executed, Ret: 1, Successful:True
6/28/2006 21:37:48.227 | DEBUG | ExecuteThread ID: 456 | Executing Script: DATA_POLLING.ips.php ~ Sender: TimerEvent
6/28/2006 21:37:48.237 | DEBUG | VariableManager | Variable: GRAPH_LOOP_COUNTER (Integer), Value: 3
6/28/2006 21:37:48.237 | DEBUG | RRDTool | Queued [Size: 23]: update /IP-Symcon/graphs/floor.rrd N:24.200000762939:5.5
6/28/2006 21:37:48.237 | DEBUG | RRDTool | Queued [Size: 24]: graph /IP-Symcon/graphs/floor.png --start -432000 --end -300 --width 420 --height 180 --color CANVAS#ffffff --color BACK#ffffff --color FONT#000000 --color MGRID#80C080 --color GRID#808020 --color FRAME#808080 --color ARROW#FFFFFF --color SHADEA#404040 --color SHADEB#404040 --lower-limit 5 --upper-limit 35 --rigid DEF:actual=/IP-Symcon/graphs/floor.rrd:actual:AVERAGE DEF:target=/IP-Symcon/graphs/floor.rrd:target:AVERAGE LINE2:actual#00af00:actual_temperature LINE2:target#ef8e00:target_temperature
6/28/2006 21:37:48.237 | DEBUG | ExecuteThread ID: 456 | Execution Result:
6/28/2006 21:37:48.237 | DEBUG | ExecuteThread ID: 456 | Executed, Ret: 1, Successful:True
6/28/2006 21:37:48.708 | DEBUG | ExecuteThread ID: 476 | Executing Script: LEVEL_0_LIGHT.ips.php ~ Sender: TimerEvent
6/28/2006 21:37:48.708 | DEBUG | VariableManager | Variable: LEVEL_0_PIRI_MOVE_DETECT (Boolean), Value: False
6/28/2006 21:37:48.708 | DEBUG | ExecuteThread ID: 932 | Executing Script: LEVEL_0_LIGHT.ips.php ~ Sender: Variable: LEVEL_0_PIRI_MOVE_DETECT, Trigger: OnUpdate
6/28/2006 21:37:48.718 | DEBUG | VariableManager | Variable: LEVEL_0_SU_LIGHT (Boolean), Value: False

weiss jetzt nicht mehr, was falsch läuft. Ich werde mal den Designer losklemmen !

mfG Franz

@paresy !

Schau dir mal bitte meine LogFile an, und erklär mir, warum das RRDTool fast 2 Stunden läuft, und dann plötzlich abschmiert !

Ich versteh es nicht !

mfG Franz

logfile1151524408.rar (80.4 KB)

Hallo, das kann ich bestätigen, auch ich konnte den Designer heute erst neu connecten, nachdem ich die RDDTool. exe im Taskmanager abgeschossen habe und IPS neu gestartet wurde.

Sehr komisch, was bei dir passiert.

  1. Bei mir haut RRD jede Minute ca. 50 Einträge in den Queue und dann arbeitet IPS das ohne murren ab. Keine Timeouts in 3 Tagen. Bei dir scheint aber irgendwas nicht OK zu sein, weil er nach einem Timeout garnicht mehr weitermacht. Braucht eine Grafik bei dir mehr als 30Sekunden zum genrieren!? (das ist der Timeout Wert)

  2. Läuft deine CPU auf 100%, sodass RRDTool nicht mit der abarbeitung nachkommt? (ggf zum Timeout Zeitpunkt?)

  3. Guck mal in /logs/rrd.log, ob da irgendwelche Erros sind!?

  4. Wenn IPS abstürzt, kann es seine RRDTool.exe nicht beenden. Deswegen habt ihr pro Absturz ein rrdtool.exe Zombie im Taskmanager

kriege ich von vorherein die Fehlermeldung „Couldn’t connect Designer to Port 3774“, und konnte auch von nirgendwo den Designer starten. Ich musste erst alle RRDTool.exe’s aus dem Taskmanager manuel schliessen, damit ich den Designer wieder starten konnte !
Irgendwie schräg !

Das muss ich mir mal angucken…

paresy

Hallo,

zu Punkt 1. : Alles läuft super für eine gewisse Zeit, dann irgendwann, ist Schluss, ohne triftigen Grund ! Nein, Grafiken brachen keine 30 Sekunden.

Punkt 2.: Nein, ist mit der neuen Beta ja behoben !

Punkt 3. Nein, nur Ok’s und Bildformat Angaben der generierten PNG’s

Punkt 4. Das leuchtet mir ein, nur danach kann man den Designer nicht mehr starten.

Ich habe dir meine Log geschickt, und das ist ja aber nicht aussergewöhnliches drin, deshalb verstehe ich es auch nicht !
ich habe gestern abend dennoch mal was versucht: Ich war gerade zufällig davor, als die Queue anfing, zu wachsen, dann habe ich einfach manuell RRDTool.exe gestoppt im Taskmanager, IPS zeigt an „RRDTool died“ und dann nach 10 Sekunden wurden auf einmal alle RRD-Befehle, die sich im Queue angesammelt hatten, ausgeführt. Und IPS hatte RRDTool.exe wieder firsch geladen !
Nun, könnte es sein, dass sich RRDTool mit was anderem nicht verträgt? Sei es Firewall, Anti-Virus, Speichermanager, o.ä? Ich werde mal weiter beobachten.

Auf jeden all, RRDTool.exe alleine funktionniert , nur nicht über das IPS Modul !

mfG Franz

So, ich hatte wärend 2 Stunden IPS mit dem RRD_Modul 3 auf 3 verschiedenen Rechnern laufen mit 3 verschiedenen Konfiguration und CPU Leistungen, und auf allen 3 hing sich IPS nach ungefähr 1 Stunde auf wegen dem RRD_Execute !

mfG Franz

Ich komme mir wieder so alleine vor in diesem Thread mit diesem Problem !

@paresy: Ich habe die Befehlszeile meiner RRDTol graph ein wenig gekürzt.
Es scheint ein wenig länger zu laufen, als nur eine Stunde.

Betreffend Timeout, es vergehen keine 30 Sekunden. Hier kann man das deutlich sehen:

6/29/2006 19:28:43.142 | DEBUG | ExecuteThread ID: 2656 | Executed, Ret: 1, Successful:True
6/29/2006 19:28:43.142 | DEBUG | ExecuteThread ID: 2660 | Execution Result:
6/29/2006 19:28:43.142 | DEBUG | ExecuteThread ID: 2660 | Executed, Ret: 1, Successful:True
6/29/2006 19:28:48.111 | DEBUG | RRDTool | Command Timeout # Command: graph /IP-Symcon/graphs/wc.png --start -432000 --end -300 --width 420 --height 180 --lower-limit 5 --upper-limit 35 --rigid DEF:actual=/IP-Symcon/graphs/wc.rrd:actual:AVERAGE DEF:target=/IP-Symcon/graphs/wc.rrd:target:AVERAGE LINE2:actual#00af00:actual_temperature LINE2:target#ef8e00:target_temperature
6/29/2006 19:28:48.111 | DEBUG | RRDTool | Send: graph /IP-Symcon/graphs/floor.png --start -432000 --end -300 --width 420 --height 180 --lower-limit 5 --upper-limit 35 --rigid DEF:actual=/IP-Symcon/graphs/floor.rrd:actual:AVERAGE DEF:target=/IP-Symcon/graphs/floor.rrd:target:AVERAGE LINE2:actual#00af00:actual_temperature LINE2:target#ef8e00:target_temperature
6/29/2006 19:28:53.126 | DEBUG | ExecuteThread ID: 1604 | Executing Script: RST_ROOT.ips.php ~ Sender: TimerEvent
6/29/2006 19:28:53.126 | DEBUG | VariableManager | Variable: RST_LOOP_COUNTER (Integer), Value: 0
6/29/2006 19:28:53.126 | DEBUG | ExecuteThread ID: 1604 | Execution Result:
6/29/2006 19:28:53.126 | DEBUG | ExecuteThread ID: 1604 | Executed, Ret: 1, Successful:True
6/29/2006 19:29:00.220 | DEBUG | ExecuteThread ID: 2528 | Executing Script: TimerEvent.ips.php ~ Sender: TimerEvent
6/29/2006 19:29:00.220 | DEBUG | VariableManager | Variable: LastTimer (Integer), Value: 1151602140
6/29/2006 19:29:00.220 | DEBUG | ExecuteThread ID: 2528 | Execution Result:
6/29/2006 19:29:00.220 | DEBUG | ExecuteThread ID: 2528 | Executed, Ret: 1, Successful:True
6/29/2006 19:29:03.126 | DEBUG | ExecuteThread ID: 2680 | Executing Script: RST_ROOT.ips.php ~ Sender: TimerEvent
6/29/2006 19:29:03.126 | DEBUG | VariableManager | Variable: RST_LOOP_COUNTER (Integer), Value: 1
6/29/2006 19:29:03.126 | DEBUG | VariableManager | Variable: KITCH_RST_TRIGGER (String), Value: TimerEvent
6/29/2006 19:29:03.126 | DEBUG | ExecuteThread ID: 2656 | Executing Script: KITCH_RST.ips.php ~ Sender: RunScript
6/29/2006 19:29:03.126 | DEBUG | ExecuteThread ID: 2680 | Execution Result:
6/29/2006 19:29:03.126 | DEBUG | ExecuteThread ID: 2680 | Executed, Ret: 1, Successful:True
6/29/2006 19:29:03.126 | DEBUG | ExecuteThread ID: 2656 | Execution Result:
6/29/2006 19:29:03.126 | DEBUG | ExecuteThread ID: 2656 | Executed, Ret: 1, Successful:True
6/29/2006 19:29:13.126 | DEBUG | ExecuteThread ID: 4036 | Executing Script: RST_ROOT.ips.php ~ Sender: TimerEvent
6/29/2006 19:29:13.126 | DEBUG | VariableManager | Variable: RST_LOOP_COUNTER (Integer), Value: 2
6/29/2006 19:29:13.126 | DEBUG | VariableManager | Variable: SALA_RST_TRIGGER (String), Value: TimerEvent
6/29/2006 19:29:13.126 | DEBUG | ExecuteThread ID: 192 | Executing Script: SALA_RST.ips.php ~ Sender: RunScript
6/29/2006 19:29:13.126 | DEBUG | ExecuteThread ID: 192 | Execution Result:
6/29/2006 19:29:13.126 | DEBUG | ExecuteThread ID: 192 | Executed, Ret: 1, Successful:True
6/29/2006 19:29:13.126 | DEBUG | ExecuteThread ID: 4036 | Execution Result:
6/29/2006 19:29:13.126 | DEBUG | ExecuteThread ID: 4036 | Executed, Ret: 1, Successful:True
6/29/2006 19:29:19.126 | DEBUG | RRDTool | Command Timeout # Command: graph /IP-Symcon/graphs/floor.png --start -432000 --end -300 --width 420 --height 180 --lower-limit 5 --upper-limit 35 --rigid DEF:actual=/IP-Symcon/graphs/floor.rrd:actual:AVERAGE DEF:target=/IP-Symcon/graphs/floor.rrd:target:AVERAGE LINE2:actual#00af00:actual_temperature LINE2:target#ef8e00:target_temperature
6/29/2006 19:29:19.126 | DEBUG | RRDTool | Send: graph /IP-Symcon/graphs/kid1.png --start -432000 --end -300 --width 420 --height 180 --lower-limit 5 --upper-limit 35 --rigid DEF:actual=/IP-Symcon/graphs/kid1.rrd:actual:AVERAGE DEF:target=/IP-Symcon/graphs/kid1.rrd:target:AVERAGE LINE2:actual#00af00:actual_temperature LINE2:target#ef8e00:target_temperature
6/29/2006 19:29:23.126 | DEBUG | ExecuteThread ID: 192 | Executing Script: SET_DAY_STATUS.ips.php ~ Sender: TimerEvent

und so geht es weiter :confused:

mfG Franz

So Paresy,

hier nun folgendes:

Siehe dir diese Logfile an:

6/30/2006 12:52:14.125 - Hier ist die Queue auf 35 schon angewachsen. RRDTool.exe scheint sich aufgehängt zu haben ??!

Dann schiesse ich RRDTool.exe im Taskmanager ab !
6/30/2006 12:52:42.578

Dann starte ich das Skript nochmal, fülle das Queue zusätzlich mit Befehlen, IPS startet RRD erneut, und siehe da, alle Meldungen, 35+13 Neue werden alle auf einen Schlag abgearbeitet !

6/30/2006 12:53:18.546 bis 6/30/2006 12:53:25.46

Mehr deutlich kann ich es nicht machen. Irgendwie scheint das was schiefzulaufen, nur weiss ich nicht was ??

mfG Franz

logfile1151671719.rar (12.5 KB)

Sind deine .png’s gelocked wann das rrdtool die graphs wegschreiben möchte?
Das hatte ich mal im bezug zum webinterface. (Franz… guckt mal das originale script von mir an - am ende stehen die satze dazu)
Deshalb habe ich erst weggeschrieben in ein temp-verzeichnis, und nach die arbeit die graphics kopiert in die richtige verzeichnis.

my 2 cents.
Fredje

Dieser Gedanke kam mir auch kürzlich, habe ihn dann aber verworfen, da Paresy ja sagt, die Befehle werden zwischengepuffert im Queue.

Also, ich habe mich mittlerweise darauf festgelegt, dass es an der Syntax der Befehlszeile liegen muss !
Da die an sich ziemlich nah an der von deinen Grafiken liegt, glaube ich fast, dass du diese Problem auch haben wirst, falls du RRD_EXecute benutzen würdest.

Ich denke, RRD_Execute wurde genau auf die Syntax von den Bedürfnissen von den Usern des Webinterface zugeschnitten. Ausserdem frage ich mich, ob diese Version von RDDTool.exe nicht buggy ist, oder eine Beta ist ? Auf der anderen Seite wiederum geht es ja perfekt, wenn ich RRDTool.exe direkt benutze, und nicht über das RRD_Execute ??

mfG Franz

Hallo Franz,

das ist so korrekt. Damit eins nach dem anderen abgearbeitet wird und die Last nicht durch 30 auf einmal laufende RRDs ins Unermessliche schiesst.

Also, ich habe mich mittlerweise darauf festgelegt, dass es an der Syntax der Befehlszeile liegen muss !
Da die an sich ziemlich nah an der von deinen Grafiken liegt, glaube ich fast, dass du diese Problem auch haben wirst, falls du RRD_EXecute benutzen würdest.

Die Syntax ist doch immer die gleiche, daran kann es nicht liegen.

Ich denke, RRD_Execute wurde genau auf die Syntax von den Bedürfnissen von den Usern des Webinterface zugeschnitten.

falsch, das hat damit nix zu tun. Es wurde zum einen deshalb gemacht, weil dadurch eine bessere Lastverteilung moeglich ist (auch bei kleineren Rechnern) und weil unter anderem auch Du immer wieder das Problem mit den DOS Fenstern aufgeworfen hast. Konkret also das IPS_Execute Problem.

Ausserdem frage ich mich, ob diese Version von RDDTool.exe nicht buggy ist, oder eine Beta ist ? Auf der anderen Seite wiederum geht es ja perfekt, wenn ich RRDTool.exe direkt benutze, und nicht über das RRD_Execute ??

mfG Franz

Damit ist eigentlich eher klar, dass das Problem woanders liegt. Aber ich gehe davon aus, dass paresy auf der Suche danach ist.

Gruss Torro

Ausserdem frage ich mich, ob diese Version von RDDTool.exe nicht buggy ist, oder eine Beta ist ? Auf der anderen Seite wiederum geht es ja perfekt, wenn ich RRDTool.exe direkt benutze, und nicht über das RRD_Execute ??

Es ist genau nicht klar. Das Problem ist ja, dass ich in meinem RRDTool Modul keine Antwort bekomme. (Nur zur Info: Ich sende den Befehl und warte dann darauf dass auf der stdout pipe Daten kommen. Wenn etwas kommt, wird es ausgewertet und der nächste Befehl ist dran). Bei Guyabano kommt aber ab und zu keine Antwort. Kein OK, aber auch kein ERROR oder sonstiges.

Wenn er nun jeden Befehl einzeld per exec() raushaut, prüft er ja nicht, ob eine Ausgabe seitens RRD da ist, oder? (Möglich wäre es ja!)
Es kann also sein, dass RRD seinen Befehl ausführt, sich beended, aber keine Ausgabe macht. Dann würde es mit exec() super laufen, weil du nicht darauf wartest bis jemand die Ausführung mit OK bestätigt.

Interessant wäre, ob die Grafik, die bei einem Timeout generiert sein sollte, auch wirklich da ist.

Grüße, paresy

Ehhmm … schliesse mich da nicht zu hin … meiner RRD gibt nach dem graph befehl per con (und nicht stdout (=kein unix/linux)) keine OK oder ERROR aber zb. ‚160x140‘.
Könnte mal probieren die antworte ab zu fangen.
Nuzt ihr vielleicht eine andere version des RRD’s? Franz und ich habe die 1.2.10 version von Tobias in w32 build.

my 2 cents wie immer

Interessant wäre, ob die Grafik, die bei einem Timeout generiert sein sollte, auch wirklich da ist.

Das könnte ich ja mal versuchen !

@GGGss: Es ist eine total andere Version von RRDTool. Ich habe sie sogar selbst nicht auf der Seite von Tobi gefunden im Downloadberech, kann deshalb auch nicht sagen, welche Version es ist. Eine andere Version von RRDTool in IPS wird mit „RRDTool died…“ quittiert , deshalb muss man diese Version benutzen !

mfG Franz

Hallo Ihr Zwei!,

manchmal seid Ihr etwas kompliziert. Man kann doch die Version ganz einfach abfragen…:stuck_out_tongue:

RRDtool 1.2.12  Copyright 1997-2005 by Tobias Oetiker <tobi@oetiker.ch>
               Compiled Feb  3 2006 00:41:10

Usage: rrdtool [options] command command_options

Valid commands: create, update, updatev, graph, dump, restore,
                last, first, info, fetch, tune, resize, xport

RRDtool is distributed under the Terms of the GNU General
Public License Version 2. (www.gnu.org/copyleft/gpl.html)

For more information read the RRD manpages

Gruss Torro