PRESENCE: another check is currently running [update]

Begonnen von arthur_dent_2015, 13 Juli 2017, 17:52:27

Vorheriges Thema - Nächstes Thema

f-zappa

PRESENCE-Devices benutze ich schon länger (LAN-Ping und function) und kannte diese Probleme bis vor kurzem nicht. Seit einiger Zeit habe ich zusätzlich Bluetooth-Devices mit reingenommen (zur Konfiguration: Ich benutze einen collectord, der sich an einen presenced und einen lepresenced verbindet, beide auf den gleichen Adapter - soll aber eigentlich möglich sein).

Naja, seitdem habe ich alle paar Tage Probleme mit einem aufgefressenen Arbeitsspeicher durch den presenced, den ich bisher auch beschuldigt habe. Der presenced wächst innerhalb einiger Tage auf ~400M, bis das Problem sich bemerkbar macht. Die Symptome zu dem Zeitpunkt ähneln den hier beschriebenen ("another check is currently running" .. "kann nicht fork()en, kein freier Speicher"). Interessanterweise hilft durchstarten des presenced zwar dem RAM, aber nicht den betroffenen PRESENCE-Devices - die bleiben in einem undefinierten Zustand hängen, bis ich FHEM durchstarte.

Nachdem ich den Thread hier gelesen habe, frage ich mich, ob der presenced da überhaupt Schuld hat oder ob er durch irgendein Verhalten des PRESENCE-Moduls an eine Grenze gebracht wird.

Markus Bloch

Dieses Problem mit ansteigendem Speicherverbrauch von presenced habe ich ebenfalls schonmal gehört. Kann ich bei mir aber nicht nachstellen. Ich habe eine durchgängig laufende Installation von presenced auf einem Raspi zusammen mit einem collectord und der Speicherverbrauch ist konstant niedrig bei 0,8%. Der collectord hat 1,1%.

Gruß
Markus

Developer für Module: YAMAHA_AVR, YAMAHA_BD, FB_CALLMONITOR, FB_CALLLIST, PRESENCE, Pushsafer, LGTV_IP12, version

aktives Mitglied des FHEM e.V. (Technik)

arthur_dent_2015

Moin Markus,
im FHEM Log gibt es, auch bei verbose 5, keine Einträge. Mein Fhem läuft auf einem Raspi 3 mit aktuellem Jessie.
Im Moment nutze in Nmap für absent/present. Das ist aber auch nicht soooo zuverlässig :( Wenn ich ein über WLAN angebundenes device schalten will möchte ich schon sicher sein dass das Gerät zu dem Zeitpunkt auch erreichbar ist.
Gibt es eine Möglichkeit dem Problem auf die Spur zu kommen? Es muss ja einen Grund für das vorzeitige Ableben des Prozesses geben...
Gruß
Arthur

Otto123

Hallo Markus,

seit zwei Tagen wurde der Status zwei meiner Geräte in FHEM nicht mehr aktualisiert, die auf die gleiche IP Adresse zielen.
defmod LGwebOSTV PRESENCE lan-ping 192.168.178.70 10 30
defmod LG_WOL WOL 3C:CD:93:99:10:33 192.168.178.70 UDP

Alle anderen PRESENCE und WOL Geräte funktionieren. Ähnliche Definitionen auf anderen FHEM Instanzen (Ziel ist die gleiche IP) funktionierten auch durchgängig.

Ein einfaches defmod ... (also einfache execute in der Raw Def) hat das Problem soeben behoben.

Hat das eventuell etwas mit deiner momentanen "Problem Forschung" zu tun? Kann ich da irgendetwas dazu beitragen? Ist allerdings hier bisher nur einmal aufgetreten.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

moskito

Hi,

hatte früher ebenfalls die Problematik, als ich über lan-ping ca. 15 Devices überwacht habe.
Inzwischen habe ich es auf 7 reduziert und es verhält sich so, wie es soll.
Der RAM war nie das Problem, sondern wohl eher, dass sich irgendwas "verharkt" hatte.

Gruß
Danny
FHEM auf Intel NUC/Proxmox & Debian 12 + HM-CFG-USB + zigbee2mqtt + Zwave + Enocean