Callmonitor 1.*

[wengi]

und nicht wieder das Einchecken vergessen

wengi

 

[buehmann]

Wer tut denn sowas? :-Ö

 

[Izzy]

Reboots nochmal

Schaut so aus, als müsste ich noch mal auf die "plötzlichen Reboots" zurückkommen. Seit ich Dropbear mit im Image habe, kommen die zwar nicht mehr 2-3 Mal am Tag vor, aber immer noch 1-2 Mal pro Woche. Da das Syslog jetzt auf meinem Loghost landet, habe ich auch eine Vergleichsmöglichkeit - und in allen Fällen, die ich mir gerade angeschaut habe, bricht die Sache scheinbar mitten in einer CallMonitor Aktion zusammen:

Sep 30 19:00:24 fritz.box callmonitor: [220] event detected:
Sep 30 19:00:24 fritz.box callmonitor:   EVENT=in:request
Sep 30 19:00:24 fritz.box callmonitor:   SOURCE='0177XXXXXXX'
Sep 30 19:00:24 fritz.box callmonitor:   DEST='XXXXXXXX'
Sep 30 19:00:24 fritz.box callmonitor: [220:0] ACTION: 'rawmsg -t "%s" 192.168.X.XX:7777 "${SOURCE:-0}"'
Sep 30 19:00:24 fritz.box callmonitor: [220:1] ACTION: 'dreammessage dreambox'
Sep 30 19:02:05 fritz.box callmonitor: [222] event detected:
Sep 30 19:02:05 fritz.box callmonitor:   EVENT=in:request
Sep 30 19:02:05 fritz.box callmonitor:   SOURCE='0177XXXXXXX'
Sep 30 19:02:05 fritz.box callmonitor:   DEST='XXXXXXXX'
Sep 30 19:02:06 fritz.box callmonitor: [223] event detected:
Sep 30 19:02:06 fritz.box callmonitor:   EVENT=in:cancel
Sep 30 19:02:06 fritz.box callmonitor:   SOURCE='0177XXXXXXX'
Sep 30 19:02:06 fritz.box callmonitor:   DEST='XXXXXXXX'
Sep 30 19:05:08 fritz.box dropbear[1158]: Running in background

Wie zu sehen, fehlt [223:X] - stattdessen folgt die Startmeldung von dropbear. Interessant vielleicht auch:

Sep 30 18:57:15 fritz.box kernel: [speedup] -> 125 MHz
Jan  1 01:00:55 fritz.box kernel: CPU revision is: 00018448

(Syslog ist auf dem Loghost nach Leveln gesplittet). Das ist deshalb interessant, weil es zeigt, dass von 18:57:15 bis zum "Absturz & Reboot" um ca. 19:02 die Box auf "full power" (125 MHz) lief, ohne wieder auf halbe Taktrate zu gehen (was normalerweise nach ca. 2 Minuten wieder geschieht, dem Log zufolge). Könnte an einem "DDos Anrufer" gelegen haben - man sieht ja, dass immer der gleiche Anrufer es nach weniger als 2 Minuten erneut probiert hat Zusammen mit einem anderen Anrufer seit 18:48 (mit einem kurzen "Loch" von 3 Minuten, kurz vor dem zitierten Speed-Up)

Vielleicht sollte ich beide Logs mal zusammenführen, um ein paar mehr Muster zu erkennen. Aber es kommt noch ein anderer Punkt hinzu: "dreammessage" scheint (zumindest bei mir) nicht richtig zu tun: Es wird zwar aufgerufen, aber auf der Box wird nix angezeigt (fiel mir gestern auf). Das könnte u.U. darauf hindeuten, dass irgendwann einmal die Sockets ausgehen (im Falle das sie erst bei Erfolg wieder abgebaut werden, was sich meiner Kenntnis entzieht).

Tipps zur genaueren Eingrenzung nehme ich gern entgegen

@buehmann: Wenn Du das komplette Log (oder Teile davon, sagen wir mal das letzte Lauf-Intervall) haben möchtest, schicke ich es Dir gern per PN oder EMail zu, lass es mich einfach wissen.

Beste Grüße,
Izzy.

 

[hermann72pb]

Hm, so weit hatte ich es noch nicht gebracht über das Reboot zu loggen und die Reboots kommen bei mir letzte Zeit eher selten vor und eher aus anderen Gründen.

Es sieht aber meiner Konfiguration verdammt ähnlich aus: Auch ich habe immer dropbear+callmonitor auf dem Board. Und auch ich kann mich dunkel daran erinnern, dass die meisten Probleme kamen, wenn es öfter "geklingelt" hat.

Als typischer "Klassiker" sei das Anrufen während eines vorhandenen Gesprächs angemerkt. Verständlicherweise mit dem dazugehörigen "Anklopfen" und einer anklopfenden Person mit einem Haufen an Durchsetzungsvermögen. Ich kann zwar nicht behaupten, dass es reproduzierbar immer in die Hose gegangen war, es gab aber schon mal Reboots in solchen Situationen und sonstige Nebeneffekte danach, dass z.B. eins der dreier Analogtelefon-Ports plötzlich "abgestorben" war. Aktionen waren ausschließlich AYACs und YACs, sodass ich eher tippen würde, dass es vom Aktionstyp nicht wesentlich abhängt.

Die Nebeneffekte, wie "leere Anzeige" kommen bei mir auch ab und zu vor. Helfen dabei kann man sich nur mit reboot der Box.

MfG

 

[Telefonmännchen]

Ich habe leider keinen externen Loghost, der ständig durchläuft, habe aber auch mit sporadischen Merkwürdigkeiten, die ich auf den Callmonitor zurückführe zu kämpfen. Eine Sache habe ich lösen können, hatte das falsche Netzteil mit zu wenig Leistung dran, so daß sich meine Box ab und zu bei Annahme eines Gespräches verabschiedet hat.

Davon unabhängig ist das andere Verhalten nicht so nachvollziehbar. Ich habe ich schon verschiedene Vermutungen angestellt, konnte aber noch nichts nachvollziehen, da ich noch keine Gemeinsamkeiten feststellen konnte. Eventuell kommt die Box beim Suchen des Telefonbucheintrages entweder in den Telefonbüchern der Box oder des Öffentlichen ins Straucheln (siehe auch Deine Beobachtungen bzgl. des Absturzzeitpunktes in Deinem Syslog). Im Moment läuft bei mit der Callmonitor wegen der Fehlersuche mit Debug-Ausgaben (ins System-Log) ohne Auffälligkeiten. Ich bleibe dran.

Gruß Telefonmännchen

 

[Izzy]

Guter Tipp - ich werde ab und an auch mal die logger Prozesse zählen gehen. Derzeit sind es genau zwei: Einer für info, einer für debug. Aber die Box hat ja auch gerade vor 3 Stunden gebootet. Muss ich morgen Abend mal schauen, wenn es wieder ein paar Anrufe gegeben hat.

Gruß,
Izzy.

 

[ao]

Hallo Izzy,

meinst Du mit "Loghost", dass Du die Logs auf einem NAS o.ä. speicherst, oder wie genau? Ich würde nämlich auch gerne dazu beitragen, das Problem weiter einzugrenzen, habe aber prinzipiell dasselbe Problem, dass die Logs beim Reboot weg sind.

@Andreas et al. - mir ist außerdem folgendes aufgefallen:
Jemand ruft an, und es klingelt - sagen wir 5x. Der Callmonitor zeigt dann 5x im Abstand von ein paar Sekunden immer wieder denselben Anruf an. Ich weiß jetzt nicht mehr genau, ob die n Anzeigen des CM mit den n Klingelsignalen identisch sind und ob das überhaupt unbeabsichtigt ist, wollte es hier aber mal ansprechen. Mit anderen Worten: Ist es normal, dass der CM bei längerem Klingeln immer wieder dasselbe im Sekundenabstand anzeigt, bis der Anruf angenommen oder abgebrochen wird?

 

[Izzy]

meinst Du mit "Loghost", dass Du die Logs auf einem NAS o.ä. speicherst, oder wie genau?

Volltreffer. Habe da eine Buffalo LinkStation mit OpenLink drauf. Das Teil dient mir u.a. als FileServer. Da mehrere Rechner darauf zugreifen (u.a. auch der Laptop meiner Frau, auch wenn ich nicht da bin), läuft das Ding eh 24/7. Also hab ich es gleich zum Loghost gemacht

Ich würde nämlich auch gerne dazu beitragen, das Problem weiter einzugrenzen, habe aber prinzipiell dasselbe Problem, dass die Logs beim Reboot weg sind.

Das war der Grund für den Loghost. Der einzige minimale Nachteil gegenüber einem lokal gespeicherten Syslog (auf USB-Stick z.B.) ist, dass u.U. mal ein Eintrag verschütt gehen kann - läuft ja mit UDP, nicht TCP. Aber ich denke, das ist minimal. Wenn Du also einen 24/7 Rechner stehen hast, und kein USB-Storage an der Fritte, ist das eine ganz brauchbare Lösung.

Jemand ruft an, und es klingelt - sagen wir 5x. Der Callmonitor zeigt dann 5x im Abstand von ein paar Sekunden immer wieder denselben Anruf an.

Das habe ich so allerdings noch nicht beobachtet. Was ich aber bestätigen kann, ist der Verdacht von hermann72pb - nämlich dass die Abstürze meist dann auftreten, wenn sich eingehende Anrufe "stapeln". Auch die Anmerkung von Telefonmännchen bzgl. der Nachschlagewerke sowie logger Prozesse ist nicht ganz von der Hand zu weisen - sondern ließe sich hier "gut kombinieren, Watson":

Bei jedem Anruf werden eine Reihe Prozesse "geforkt" - die Rückwärtssuche in diversen Quellen, offensichtlich in einigen Fällen zusätzliche logger, dann diverse Benachrichtigungsdienste (dreammessage, dbox, Yac, ...). Bei einem einzelnen Anruf sicher kein Problem. Stellt sich jetzt die Frage: Wann werden die Prozesse beendet - oder, genauer: Bei "horch mal wer da hämmert" werden u.U. mehr Prozesse gestartet, als die Box verkraftet - oder es verhakeln sich welche, oder irgendwelche anderen Limits werden gesprengt.

Wäre also die Frage an buehmann: Auf was sollten wir besonders achten - irgend eine Idee?

Ob das Netzteil sich irgendwann überlastet fühlt (siehe Link von Telefonmännchen), kann man sicher nicht ausschließen. Wie hoch da die Wahrscheinlichkeit ist, wäre eine andere Frage. Und selbst wenn, wäre gleich die zweite Frage, was diese "Überlast" denn auslöst, bzw. wie man selbige vermeiden kann...

Beste Grüße,
Izzy.

 

[Telefonmännchen]

Der einzige minimale Nachteil gegenüber einem lokal gespeicherten Syslog (auf USB-Stick z.B.) ist, dass u.U. mal ein Eintrag verschütt gehen kann...

Dafür hast Du gegenüber dem USB-Stick den Vorteil, daß dort das Dateisystem durch einen Absturz im ungünstigen Augenblick (beim Schreiben) nicht beschädigt werden kann. Solch einen Kandidaten habe ich hier gerade liegen, stammt aber nicht von der Box. Da hatte jemand anders zu flinke Finger und weint seinen Daten hinterher.

... Anmerkung von Telefonmännchen bzgl. der Nachschlagewerke sowie logger Prozesse ...

Ich meine, daß einige Merkwürdigkeiten auch im Zusammenhang mit Anrufen ohne Übermittlung der Rufnummer aufgetreten sind. Leider kann ich das nicht nachvollziehen, sondern ist nur eine Vermutung, weil ich Logger und Anrufe gezählt habe und vermute, daß bei mir pro Anruf ein Logger dazukam. Im Moment habe ich zwei Logger (einen daemon.info und einen daemon.debug) das sollte auch so sein, weil ich das Logging des CM in das Syslog eingeschaltet habe und auch die entsprechenden Tasks laufen.

... die zweite Frage, was diese "Überlast" denn auslöst, bzw. wie man selbige vermeiden kann...

Ich denke mal, zu allererst, indem man das richtige Netzteil benutzt. Ansonsten sind die Möglichkeiten da eher begrenzt und ich gehe mal davon aus, daß das originale Netzteil die Box bei 100%-CPU-Auslastung und eventueller angeschlossenen Peripherie betreiben kann. Sicherlich sind dort auch Grenzen gesetzt (Stichwort: USB-Festplatte u.a.), aber eine Handbuch-gerechte Installation (ein ISDN-Telefon ohne eigene Spannungsversorgung, evtl. zwei Analogtelefone und einen USB-Stick) sollte sie schon versorgungspannungsmäßig verkraften können. Wobei, sehr hochwertig scheinen die mitgelieferten Teile auch nicht zu sein, wenn man sich die Threads mit den quietschenden NTs anschaut. Ist aber schon eine Weile her.

Gruß Telefonmännchen

 

[buehmann]

Hallo,

dass derselbe Anruf 5-mal gemeldet wird, sollte nicht passieren (und kann es eigentlich auch nicht, außer wenn die Box dem Callmonitor tatsächlich fünf Anrufe meldet (oder wenn wie bei Telefonmännchens Problemen beim Restart des Callmonitors auf einmal mehrer Callmonitore laufen)).

Bei jedem Anruf werden eine Reihe Prozesse "geforkt"

Ja, z.B. einer pro Regel in den Listeners.

- die Rückwärtssuche in diversen Quellen

Das meiste davon passiert nacheinander; nur die max. zwei Rückwärtssuchen im Netz werden parallel erledigt.

offensichtlich in einigen Fällen zusätzliche logger

Nein, logger (maximal zwei: info + debug) werden nur bei der Initialisierung des Callmonitors gestartet und bleiben dann über die gesamte Laufzeit erhalten.

Stellt sich jetzt die Frage: Wann werden die Prozesse beendet

Wenn die Prozesse mit ihrer Arbeit fertig sind (also die Rückwärtssuche/Regelbearbeitung/Benachrichtigung erledigt haben)

werden u.U. mehr Prozesse gestartet, als die Box verkraftet - oder es verhakeln sich welche, oder irgendwelche anderen Limits werden gesprengt.

Alles möglich. Andererseits hatte ich diesen Überlastungsverdacht ganz zu Beginn der Diskussion über Hänger schon einmal und habe damals einen Stresstest durchgeführt, also den Callmonitor mit generierten Anrufen so schnell gefüttert, wie es nur ging. Dabei blieb alles stabil. (Das schließt natürlich nicht aus, dass ein bestimmtes Muster von Anrufen mit einem bestimmten Timing etwas anderes hervorruft.)

Wäre also die Frage an buehmann: Auf was sollten wir besonders achten - irgend eine Idee?

Irgendwelche Daten über Ressourcenauslastung (CPU, RAM, Load, ...) wären vielleicht nützlich, aber die Schwierigkeit dürfte darin bestehen, die Messwerte vor einem Absturz noch rechtzeitig auf einen anderen Rechner zu bekommen.

Gruß,
Andreas

 

[Izzy]

Dafür hast Du gegenüber dem USB-Stick den Vorteil, daß dort das Dateisystem durch einen Absturz im ungünstigen Augenblick (beim Schreiben) nicht beschädigt werden kann.

Das war einer der Gründe für meine Entscheidung. Der zweite folgt weiter unten.

Ich meine, daß einige Merkwürdigkeiten auch im Zusammenhang mit Anrufen ohne Übermittlung der Rufnummer aufgetreten sind.

So einen Kandidaten hatte ich heute gerade. Bei "unbekannten" Anrufern habe ich den Listener so konfiguriert, dass er als Rufnummer eine "0" liefert. Die kann ich dann lokal mit "WolleRoseKaufe" übersetzen, was auch prima klappt. Heute hatte ich allerdings eine leere Box dabei - ohne Nummer, ohne irgendwas. Kann aber Zufall sein.

Leider kann ich das nicht nachvollziehen, sondern ist nur eine Vermutung, weil ich Logger und Anrufe gezählt habe und vermute, daß bei mir pro Anruf ein Logger dazukam.

Dazu schrieb Andreas ja schon, dass das eigentlich nicht passieren sollte. Habe gerade nochmal die Prozessliste durchgeschaut - und das ist bei mir auch trotz mehrerer eingegangener Anrufe nicht der Fall.

Dafür läuft der CallMonitor bei mir allerdings mehrfach:

1029 root      1296 S    /bin/ash /usr/sbin/callmonitor --debug
1066 root      1296 S    /bin/ash /usr/sbin/callmonitor --debug
1068 root      1296 S    /bin/ash /usr/sbin/callmonitor --debug
1070 root      1296 S    /bin/ash /usr/sbin/callmonitor --debug

Das sollte doch eigentlich auch nicht normal sein, oder? Die vier laufen bereits seit mindestens 24 Stunden, ist aber auch kein weiterer dazugekommen.

daß das originale Netzteil die Box bei 100%-CPU-Auslastung und eventueller angeschlossenen Peripherie betreiben kann. Sicherlich sind dort auch Grenzen gesetzt (Stichwort: USB-Festplatte u.a.), aber eine Handbuch-gerechte Installation (ein ISDN-Telefon ohne eigene Spannungsversorgung, evtl. zwei Analogtelefone und einen USB-Stick) sollte sie schon versorgungspannungsmäßig verkraften können.

Da hast Du den zweiten Grund für den Loghost: Um so etwas ausschließen zu können, ist an meiner Fritte nix weiter angeschlossen: Nix per USB, und die Telebims haben auch alle ihr eigenes Netzteil (bzw. Akkus, bei den schnurlosen).

[ Forks ]

Ja, z.B. einer pro Regel in den Listeners.

Und wie viele callmonitor Prozesse sollten es normalerweise sein? Bei mir sind es, wie oben bereits erwähnt, gleich 4 Stück.

Wenn die Prozesse mit ihrer Arbeit fertig sind (also die Rückwärtssuche/Regelbearbeitung/Benachrichtigung erledigt haben)

Und wenn sie damit "nicht fertig werden" - also irgendwelche Fehler auftreten? Gibt es Timeouts, wenn z.B. ein zu benachrichtigendes Gerät nicht erreichbar ist? => Ich gehe davon aus, weil sonst da eine Menge dreammessage Prozesse hängen müssten bei mir

Alles möglich. Andererseits hatte ich diesen Überlastungsverdacht ganz zu Beginn der Diskussion über Hänger schon einmal und habe damals einen Stresstest durchgeführt

Damit bleiben dafür nur noch "besondere Konstellationen" übrig. Vielleicht ein Wechselspiel mit anderen Plugins. Ich möchte in diesem Zusammenhang nur daran erinnern, dass ich durch Hinzufügen von Dropbear (und gleichzeitiges Entfernen von Tor und Privoxy, aus Platzgründen) von zwei bis drei Abstürzen täglich auf ein bis zwei wöchentlich herunter bin - ganz auszuschließen ist das also nicht.

Irgendwelche Daten über Ressourcenauslastung (CPU, RAM, Load, ...) wären vielleicht nützlich, aber die Schwierigkeit dürfte darin bestehen, die Messwerte vor einem Absturz noch rechtzeitig auf einen anderen Rechner zu bekommen.

Es gibt ja leider keinen "OnCrash" Handler, den man abfangen könnte. Da sich die Box aber nicht einfach aufhängt, sondern neu bootet, könnte da auch der WatchDog Prozess beteiligt sein - könnte man da nicht vielleicht was einhängen?

Beste Grüße,
Izzy.

 

[buehmann]

Und wie viele callmonitor Prozesse sollten es normalerweise sein? Bei mir sind es, wie oben bereits erwähnt, gleich 4 Stück.

Das hat schon seine Richtigkeit: Schau dir mal die PPIDs der Prozesse an: Das sollten alles Kindprozesse eines Hauptprozesses sein. (Die Kinder führen gerade Teile einer Pipe aus.)

Andreas

 

[Izzy]

OK, OK - sollte ja kein Motzen sein, sondern lediglich der Verifikation dienen. Und eine Reihe von Child-Prozessen muss ja auch nicht unbedingt "gewollt" sein - auch ein "fork" kann ja mal danebengehen, gelle?

Danke also für die klare Antwort - dann ist das also auch sauber. Kennst Du Dich zufällig mit dem Wachhund aus, ob man da was einklinken kann, bevor er die Box neu startet? Ein paar LogMessages wären sicher nicht zu schwierig zu bewerkstelligen, könnte ich mir vorstellen, so a la "logger 'free RAM: blabla, xx processes, rebooting just for fun'"

Beste Grüße,
Izzy.

 

[buehmann]

Nein, ich kenne keine solche Möglichkeit. Startet denn bei dir die Box tatsächlich vollständig neu (so dass sie hinterher wieder funktioniert)? Bisher hatte ich den Eindruck, dass es um ein Aufhängen der Box geht (also nichts geht mehr, Netz nicht, Telefon nicht, ...).

Andreas

 

[Izzy]

Nee, ist ein kompletter Reboot hier. Sieht man schon an der Uptime auf der Freetz Status Seite. Und solange das nur so einmal wöchentlich passiert, raufe ich mir auch nicht die Haare aus. Meistens merke ich es eh erst irgendwann später, wenn ich die Status-Seite wieder aufrufe (und die Uptime erstaunlich niedrig ist), oder ich zufällig gerade was in den Logs suche. Nervig ist es natürlich trotzdem - vor allem, wenn der AVM DynDNS Updater nach dem Reboot ins Leere läuft, und ich gerade von unterwegs auf die Kiste daheim zugreifen will. Oder wenn's einem, wie der Zufall manchmal spielt, mitten im Telefonat die Leitung trennt...

Beste Grüße,
Izzy.

 

[Izzy]

Nochmal ein paar Neuigkeiten: Das mit den Reboots muss nicht zwangsweise das Verschulden von CallMonitor sein (auch wenn es durchaus möglich ist, dass es durch ihn ausgelöst wird). In einem anderen Thread fand ich einen interessanten Hinweis auf "heiße Elemente" - und hier brachten ein paar kleine Kühlkörperchen Abhilfe. Wenn ich meine Box anfasse, kann ich mir das gut als Wahrscheinlichkeit vorstellen.

Weiter oben schrieb ich etwas zu dem Phänomen mit der "leeren Nummer": Bitte streichen. Daran ist offensichtlich nicht CallMonitor schuld, sondern CallMonitor2 (das Tool für den PC, welches die Nummern dann anzeigen soll). Hatte es gestern wieder 4 Mal - also gleich in's Log geschaut: Jedesmal war es eine 0175xxxxxxx Nummer. Habe mir also mal die Vorwahlliste vom CallMonitor2 angeschaut: Da waren mehrere Einträge vorhanden, z.B. 0175 und 01755 - offensichtlich konnte CM2 sich dann nicht entscheiden <grins>. Habe die 01755 jetzt mal rausgeworfen, und beobachte das weiter.

Beste Grüße,
Izzy.

 

[BX-8017]

Hi.

Kann mit mal bitte jmd sagen, wie sich das mit dem message-Befehl von freetz verhält. Wird dieser Direkt von der Fritz!Box, wie in den listeners angegeben an die Box (Dream,d-box) geschickt oder wird der message Befehl in irgendeiner Datei in der FB explizit aufgerufen.

Grund der Frage ist, ich suche eine Möglichkeit, vor dem eigentlichen message Befehl noch etwas abzufragen auf der Dreambox bzw d-box.

Vielen Dank
BX-8017

 

[hermann72pb]

... Startet denn bei dir die Box tatsächlich vollständig neu (so dass sie hinterher wieder funktioniert)? Bisher hatte ich den Eindruck, dass es um ein Aufhängen der Box geht (also nichts geht mehr, Netz nicht, Telefon nicht, ...)

Unterschiedlich, meistens Box-abhängig. 7050 bleibt meistens hängen, 7170 und andere rebooten dagegen eher. Kann aber damit zusammen hängen, dass 7050 eine ältere Firmware hat. Vermutlich hat AVM was an der Watchdog-Funktionalität seither verbessert. Oder es gibt klitzekleine Hardwareunterschiede zwischen 7050 und 7170, die das ausmachen können.

Zu Hardwareproblemen/Netzteilen u ähnlichem. Es könnte durchaus sein, dass irgendein Gatter in der Box selbst teilweise beschädigt ist. Dadurch frisst die Box mehr Strom und wird heißer (meistens lokal). Wobei die heißeste Stelle nicht unbedingt den Verursacher anzeigt. Die Steckernetzteile haben überwiegend eine Strombegrenzung, die einfacherhalber primärseitig überwacht wird. Daher können relativ große Abweichungen auch innerhalb der Charge auftretten, wann die Strombegrenzung anspricht. Das Ansprechen der Strombegrenzung kann man z.B. als Pfeifen wahr nehmen, muss man aber nicht. Auf jeden Fall führt das Ansprechen der Strombegrenzung zum Abfall der Ausgangsspannung vom Netzteil. Dadurch kann mit der Box alles Mögliche passieren.

Man sollte es mit einer anderen Box ausprobieren.

MfG

 

[Izzy]

Ich auch nochmal: "Leere Nummer" war definitiv CallMonitor2 - nach o.g. Aktion tritt das nun nicht mehr auf.

Angeregt durch das angesprochene "Hitze-Problem", habe ich den Standort meiner Fritte mal investigiert und adaptiert: Sie stand in der Tat recht nahe bei einem GigaBit Router, der sich gut als Kaffeewärmer eignen könnte. Hab sie nun ein wenig abgerückt. Uptime derzeit 6,25 Tage (seit dem letzten "auto-boot"). Mal schauen. In zwei Tagen erreicht sie dann eine neue Rekordzeit - oder auch nicht...

Beste Grüße,
Izzy.

 

[ao]

Ohne Eure interessante Diskussion zum pfeifenden Netzteil stören zu wollen:
Könntet Ihr das ggf. in einen extra Thread ausgliedern?
Dieser "arme" Callmonitor-Thread ist eh schon so ellenlang. Der CM müsste ein eigenes Unterforum bekommen.