SmarthomeNG stürzt ab

[henfri]

Hallo,

in meinen Logs habe ich gesehen, dass SmarthomeNG häufiger mal neu startet.
Im Log (weder WARNING noch DEBUG) ist dabei nix wesentliches zu finden (siehe ganz unten).

Wie kann ich dem Problem näher kommen?
Ich dachte da z.B. daran die Anzahl der Scheduler und des Speicherbedarf zu monitoren... Aber vielleicht gibt es sinnvolleres?

Gruß,
Hendrik

2022-04-17 13:47:05 DEBUG plugins.onewire set dict[28.3BE0AA030000] as key:T11 <item:Abluft Lueftung temp and path:None>
2022-04-17 13:47:05 WARNING lib.item.item item 'Haustechnik.Multimedia.denon.main.Input.Music': trigger item 'Haustechnik.Multimedia.denon.main.Source' not found for function '1 if ((sh.Haustechnik.Multimedia.denon.main.Input() == 'DVD' or sh.Haustechnik.Multimedia.denon.main.Input() == 'CD' or sh.Haustechnik.Multimedia.denon.main.Input() == 'NET') and sh.Haustechnik.Multimedia.denon.main.Power()) else 0'
2022-04-17 15:47:06 WARNING lib.item.item Item og.Lina.FensterFarb.Dimmwert: problem evaluating '(sh.og.Lina.FensterFarb.R.RelativDimmen() + sh.og.Lina.FensterFarb.G.RelativDimmen() + sh.og.Lina.FensterFarb.B.RelativDimmen())/3': unsupported operand type(s) for /: 'list' and 'int'
2022-04-17 15:47:06 WARNING lib.scene Item oder Logik 'og.Till.lamellen.sued.position' nicht gefunden. Wurde in /usr/local/smarthome/scenes/eg.Arbeitszimmer.Szene spezifiziert
2022-04-17 15:47:06 WARNING lib.scene Item oder Logik 'og.Till.lamellen.sued.lamelle' nicht gefunden. Wurde in /usr/local/smarthome/scenes/eg.Arbeitszimmer.Szene spezifiziert
2022-04-17 15:47:06 DEBUG plugins.alexa4p3 validating device lina-szene
2022-04-17 15:47:06 DEBUG plugins.alexa4p3 validating device Lina_Jalousie
...
2022-04-17 15:47:06 DEBUG plugins.telegram Changing Telegrams thread names to pretty thread names
2022-04-17 15:47:06 DEBUG plugins.alexa4p3 validating device Till_Wand
2022-04-17 15:47:06 DEBUG plugins.telegram started polling the updater, Queue is <queue.Queue object at 0x7f2f5831a310>
2022-04-17 15:47:06 WARNING plugins.avdevice Initializing avdevice: Function up for zone 0 not used by any item. Re-visit items and config file!
2022-04-17 15:47:06 DEBUG plugins.alexa4p3 validating device Schreibtisch_Till
2022-04-17 15:47:06 DEBUG plugins.onewire Run method called
2022-04-17 15:47:06 WARNING plugins.uzsu Item to be set by uzsu 'og.lina.verschattung_zentral.auf_ab' does not exist. Error: 'NoneType' object has no attribute 'property'
2022-04-17 15:47:06 DEBUG plugins.alexa4p3 validating device Lichterkette_Till
2022-04-17 15:47:06 WARNING plugins.avdevice Initializing avdevice: Function menu off for zone 0 not used by any item. Re-visit items and config file!
2022-04-17 15:47:06 DEBUG plugins.onewire scheduler_add: name = plugins.onewire.sensor_discovery, parameters: prio=5, cycle=600, offset=2, next=datetime.datetime(2022, 4, 17, 15, 47, 11, 914202, tzinfo=tzfile('/usr/share/zoneinfo/Europe/Berlin'))
2022-04-17 15:47:06 DEBUG plugins.onewire scheduler_add: name = plugins.onewire.sensor_read, parameters: prio=5, cycle=120, next=datetime.datetime(2022, 4, 17, 15, 47, 21, 927972, tzinfo=tzfile('/usr/share/zoneinfo/Europe/Berlin'))
2022-04-17 15:47:06 DEBUG modules.mqtt _get_caller_type: inspect.stack()[2][1] = '/usr/local/smarthome/lib/model/mqttplugin.py', split = ['', 'usr', 'local', 'smarthome', 'lib', 'model', 'mqttplugin.py']
2022-04-17 15:47:06 DEBUG plugins.landroid Run method called
2022-04-17 15:47:06 DEBUG plugins.alexa4p3 validating device Lavalampe_Till
2022-04-17 15:47:06 DEBUG plugins.alexa4p3 validating device Sternenhimmel_Till
2022-04-17 15:47:06 NOTICE lib.smarthome -------------------- SmartHomeNG initialization finished --------------------

[henfri]

Hallo,

noch eine Beobachtung:
Das Telegram-Plugin sendet noch "SmartHomeNG Telegram Plugin stops".
Es scheint also, als würde SH beendet und würde nicht wirklich abstürzen.

Gruß,
Hendrik

[bmx]

Das Log oben zeigt eigentlich nur den Start von SHNG. Hast Du nichts vor dem Neustart geloggt?

Eventuell hast Du einen Threadmangel und SHNG startet sich deshalb neu um eben nicht abzustürzen. Aber das sollte im Log eigentlich auftauchen.

[henfri]

Hallo Bernd,

Im log steht nicht, wie SH abstürzt oder sich beendet.
Du siehst, dass die ersten zwei Log-Einträge von 13:47 sind. zwischen diesen und denen um 15:47 gab es keine Log-Einträge (in diesem Log-Level).

Zum Thema Thread-Mangel habe ich mal die Graphen konsultiert:
SH-NG.png

Das sieht ja schon danach aus.
Wie finde ich jetzt den Grund für die vielen Scheduler und Threads?

Gruß,
Hendrik

[Sisamiwe]

henfri

Startet nur shNG bei oder das ganze Gerät?
Ich hatte letzthin Probleme mit einem Raspberry Netzteil, da hatte sich der ganze RPi neu gestartet.
Wenn Du auch einen RPi nutzt, schau mal ins syslog.

Wenn zu viele Threads den shNG Neustart auslösen, wird das im Log angekündigt.

[henfri]

Nur shNG startet neu. Das Gerät läuft normal.

Zu den Threads finde ich:

2022-04-20 18:00:42 ERROR lib.scheduler Needing more worker threads than the specified maximum of 20! (20 worker threads active)
2022-04-20 18:06:44 ERROR lib.scheduler Needing more worker threads than the specified maximum of 20! (21 worker threads active)
2022-04-20 18:23:41 ERROR lib.scheduler Needing more worker threads than the specified maximum of 20! (22 worker threads active)
2022-04-20 18:40:28 ERROR lib.scheduler Needing more worker threads than the specified maximum of 20! (23 worker threads active)
2022-04-20 18:50:45 ERROR lib.scheduler Needing more worker threads than the specified maximum of 20! (24 worker threads active)
2022-04-20 19:16:43 ERROR lib.scheduler Needing more worker threads than the specified maximum of 20! (25 worker threads active)
2022-04-20 19:27:45 ERROR lib.scheduler Needing more worker threads than the specified maximum of 20! (26 worker threads active)
2022-04-20 19:46:45 ERROR lib.scheduler Needing more worker threads than the specified maximum of 20! (27 worker threads active)
2022-04-20 20:33:59 ERROR lib.scheduler Needing more worker threads than the specified maximum of 20! (28 worker threads active)
2022-04-20 20:35:29 ERROR lib.scheduler Needing more worker threads than the specified maximum of 20! (29 worker threads active)
2022-04-20 20:36:30 ERROR lib.scheduler Needing more worker threads than the specified maximum of 20! (30 worker threads active)
2022-04-20 20:36:30 WARNING lib.scheduler Worker-Threads: items.Haustechnik.Stromzaehler.Momentanleistung_1m in_c: 4, items.eg.Esszimmer.Hauptlicht.Verbrauch.heute
: 1, items.eg.Wohnzimmer.TVSchrank.Verbrauch.heute: 1, items.eg.Wohnzimmer.TVSchrank.Verbrauch.woche: 1, modules.admin.update_blog_links: 1, items.Haustechnik.Stromzaehle
r.Leistungsdurchschnitt24h: 3, items.Haustechnik.Lueftung.Verbrauch.monat: 1, items.Haustechnik.Stromzaehler.Momentanleistung_10 min_c: 3, items.Haustechnik.Lueftung.Verbr
auch.woche: 1, items.eg.Wohnzimmer.TVSchrank.Verbrauch.monat: 1, items.Haustechnik.Stromzaehler.Momentanleistung_10 min: 2, items.Haustechnik.Stromverbrauch.Dali.Aufsummie
rteLeistung.monat: 1, items.Haustechnik.Lueftung.Verbrauch.heute: 1, items.Haustechnik.Stromverbrauch.Dali.Aufsummierte Leistung.heute: 1, items.Haustechnik.Stromverbrauch
.Dali.AufsummierteLeistung.woche: 1, items.Haustechnik.Lueftung.Verbrauch.jahr: 1, items.eg.Esszimmer.Hauptlicht.Verbrauch.woche: 1, items.eg.Wohnzimmer.TVSchrank.Verbrau
ch.jahr: 1, items.eg.Esszimmer.Hauptlicht.Verbrauch.jahr: 1, items.eg.Esszimmer.Hauptlicht.Verbrauch.monat: 1, items.Haustechnik.Stromverbrauch.Dali.Aufsummierte Leistung.
jahr: 1, plugins.database.Count logs: 1

Der Stromzähler hat natürlich sehr viele Updates. Aber die Berechnung ist ja schnell - somit sollten die Threads auch schnell wieder Enden...

Hier mal ein Beispiel:

        Momentanleistung_10min:
            name: Momentanleistung_10min
            type: num
            database: 'true'
            database_maxage: 365
            knx_dpt: 14
            # knx_send = 6/7/2
            eval: (sh.Haustechnik.Stromzaehler.Zaehlerstand()- sh.Haustechnik.Stromzaehler.Zaehlerstand.db('min', '10i'))*60.0*1000.0/10.0
            eval_trigger: Haustechnik.Stromzaehler.Zaehlerstand
            influx: 'true'

und häufig verwende ich diesen Struct:

Verbrauch:
    type: num
    cycle: 60  # wenn cycle erhöht wird auch * 60.0 erhöhen
    eval: self()+ self.return_parent().Leistung() * 60.0 / 60.0 / 60.0 / 1000
    database: 'init'
    database_maxage: 365
    influx: 'true'
    Tagessumme:
        type: num
        database: 'init'
        database_maxage: 365
        eval: (sh.return_parent()-sh.return_parent().db('min', '24h'))
        crontab: '59 23 * * =1'
        influx: 'true'
        enforce_updates: 'true'  
    Wochensumme:
        type: num
        database: 'init'
        database_maxage: 365
        eval: (sh.return_parent()-sh.return_parent().db('min', '168h'))
        crontab: '59 23 * 0 =1'
        influx: 'true'
        enforce_updates: 'true'   
    heute:
        type: num
        visu_acl: ro
        eval: round((sh...() - sh...db('max', str(shtime.time_since(shtime.today(), 'im')) + 'i', str(shtime.time_since(shtime.today(), 'im')) + 'i')), 2)
        eval_trigger:
          - ..
        cache: 'true'

    woche:
        type: num
        visu_acl: ro
        eval: round((sh...() - sh...db('max', str(shtime.time_since(shtime.beginning_of_week(), 'im')) + 'i', str(shtime.time_since(shtime.beginning_of_week(), 'im')) + 'i')), 2)
        eval_trigger:
          - ..
        cache: 'true'

    monat:
        type: num
        visu_acl: ro
        eval: round((sh...() - sh...db('max', str(shtime.time_since(shtime.beginning_of_month(), 'im')) + 'i', str(shtime.time_since(shtime.beginning_of_month(), 'im')) + 'i')), 2)
        eval_trigger:
          - ..
        cache: 'true'

    jahr:
        type: num
        visu_acl: ro
        eval: round((sh...() - sh...db('max', str(shtime.time_since(shtime.beginning_of_year(), 'im')) + 'i', str(shtime.time_since(shtime.beginning_of_year(), 'im')) + 'i')), 2)
        eval_trigger:
          - ..
        cache: 'true'

    gestern:
        type: num
        visu_acl: ro
        eval: round((sh...db('max', str(shtime.time_since(shtime.today(), 'im')) + 'i', str(shtime.time_since(shtime.today(), 'im')) + 'i') - sh...db('max', str(shtime.time_since(shtime.yesterday(), 'im')) + 'i', str(shtime.time_since(shtime.yesterday(), 'im')) + 'i')), 2)
        crontab:
         - 1 0 * * = 1
         - init+20 = 1
        database: init
        database_maxage: 365

    gestern_minus1:
        type: num
        visu_acl: ro
        eval: round((sh...db('max', str(shtime.time_since(shtime.yesterday(), 'im')) + 'i', str(shtime.time_since(shtime.yesterday(), 'im')) + 'i') - sh...db('max', str((shtime.time_since(shtime.yesterday(), 'im')) + 1440) + 'i', str((shtime.time_since(shtime.yesterday(), 'im')) + 1440) + 'i')), 2)
        crontab:
         - 1 0 * * = 1
         - init+20 = 1
        cache: 'true'
    
    gestern_minus2:
        type: num
        visu_acl: ro
        eval: round((sh...db('max', str((shtime.time_since(shtime.yesterday(), 'im')) + 1440) + 'i', str((shtime.time_since(shtime.yesterday(), 'im')) + 1440) + 'i') - sh...db('max', str((shtime.time_since(shtime.yesterday(), 'im')) + 2880) + 'i', str((shtime.time_since(shtime.yesterday(), 'im')) + 2880) + 'i')), 2)
        crontab:
         - 1 0 * * = 1
         - init+20 = 1
        cache: 'true'
        
    gestern_minus3:
        type: num
        visu_acl: ro
        eval: round((sh...db('max', str((shtime.time_since(shtime.yesterday(), 'im')) + 2880) + 'i', str((shtime.time_since(shtime.yesterday(), 'im')) + 2880) + 'i') - sh...db('max', str((shtime.time_since(shtime.yesterday(), 'im')) + 4320) + 'i', str((shtime.time_since(shtime.yesterday(), 'im')) + 4320) + 'i')), 2)
        crontab:
         - 1 0 * * = 1
         - init+20 = 1
        cache: 'true'
        
    gestern_minus4:
        type: num
        visu_acl: ro
        eval: round((sh...db('max', str((shtime.time_since(shtime.yesterday(), 'im')) + 4320) + 'i', str((shtime.time_since(shtime.yesterday(), 'im')) + 4320) + 'i') - sh...db('max', str((shtime.time_since(shtime.yesterday(), 'im')) + 5760) + 'i', str((shtime.time_since(shtime.yesterday(), 'im')) + 5760) + 'i')), 2)
        crontab:
         - 1 0 * * = 1
         - init+20 = 1
        cache: 'true'

    gestern_minus5:
        type: num
        visu_acl: ro
        eval: round((sh...db('max', str((shtime.time_since(shtime.yesterday(), 'im')) + 5760) + 'i', str((shtime.time_since(shtime.yesterday(), 'im')) + 5760) + 'i') - sh...db('max', str((shtime.time_since(shtime.yesterday(), 'im')) + 7200) + 'i', str((shtime.time_since(shtime.yesterday(), 'im')) + 7200) + 'i')), 2)
        crontab:
         - 1 0 * * = 1
         - init+20 = 1
        cache: 'true'                
        
    vorwoche:
        type: num
        visu_acl: ro
        eval: round((sh...db('max', str(shtime.time_since(shtime.beginning_of_week(), 'im')) + 'i', str(shtime.time_since(shtime.beginning_of_week(), 'im')) + 'i') - sh...db('max', str(shtime.time_since(shtime.beginning_of_week(shtime.calendar_week() - 1), 'im')) + 'i', str(shtime.time_since(shtime.beginning_of_week(shtime.calendar_week() - 1), 'im')) + 'i')), 2)
        crontab:
         - 1 0 * * = 1
         - init+20 = 1
        database: init
        database_maxage: 365

    vorwoche_minus1:
        type: num
        visu_acl: ro
        eval: round((sh...db('max', str(shtime.time_since(shtime.beginning_of_week(shtime.calendar_week() - 1), 'im')) + 'i', str(shtime.time_since(shtime.beginning_of_week(shtime.calendar_week() - 1), 'im')) + 'i') - sh...db('max', str(shtime.time_since(shtime.beginning_of_week(shtime.calendar_week() - 2), 'im')) + 'i', str(shtime.time_since(shtime.beginning_of_week(shtime.calendar_week() - 2), 'im')) + 'i')), 2)
        crontab:
         - 1 0 * * = 1
         - init+20 = 1
        cache: 'true'
        
    vorwoche_minus2:
        type: num
        visu_acl: ro
        eval: round((sh...db('max', str(shtime.time_since(shtime.beginning_of_week(shtime.calendar_week() - 2), 'im')) + 'i', str(shtime.time_since(shtime.beginning_of_week(shtime.calendar_week() - 2), 'im')) + 'i') - sh...db('max', str(shtime.time_since(shtime.beginning_of_week(shtime.calendar_week() - 3), 'im')) + 'i', str(shtime.time_since(shtime.beginning_of_week(shtime.calendar_week() - 3), 'im')) + 'i')), 2)
        crontab:
         - 1 0 * * = 1
         - init+20 = 1
        cache: 'true'
        
    vormonat_zaehlerstand:
        type: num
        visu_acl: ro
        eval: round(sh...db('max', str(shtime.time_since(shtime.beginning_of_month(), 'im')) + 'i', str(shtime.time_since(shtime.beginning_of_month(), 'im')) + 'i'), 2)
        crontab:
         - 1 0 1 * = 1
         - init+20 = 1
        database: init
        database_maxage: 365

Ist daran etwas auszusetzen?

Gruß,
Hendrik

[Sisamiwe]

@henfri
Das Problem hatte ich auch, da ein Item Update seht viele Berechnung mit der DB auslöst. Das dauert seine Zeit, und wenn noch ein Update kommt, werden es noch mehr Berechnungen usw. Da laufen die Threads über.

Als nächsten Schritt hatte ich mir eine Logik für die Berechnung gebaut. Da gibt es nur einen Thread und die Berechnungen kaufen jn dem Thread nacheinander.
Das ging doch besser, aber immer noch nicht gut genug.
Und dann habe ich das DB AddinOn Plugin genau für diese Anwendung gebaut. Erstmal nur für MySQL.
Schau mal, dazu habe ich Einen Threads im Forum aufgemacht.

[henfri]

Hallo,

ja, dein Addon habe ich gesehen. Aber ich nutze sqlite.
Ich habe jetzt die ganzen evals aus dem Struct rauskommentiert, habe das Problem aber weiterhin (mehr als 10 Neustarts pro Tag :-( ).
Wie kann ich denn herausfinden, was die ganzen Worker sind?

Gruß,
Hendrik

[Msinn]

Du musst Dir anschauen, was Du als letztes geändert hast, bevor die Anzahl der Worker so anstieg, dass SmartHomNG zum Schutz Neustarts auslöst.

Dabei musst Du nach Scheduler Tasks Ausschau halten, die gleichzeitig in größerer Zahl getriggert werden. Das können auch Tasks sein, die extrem schnell abgearbeitet werden. Durch das gleichzeitige triggern wird dem Scheduler dann immer signalisiert, dass er mehr Worker braucht, weil einen Moment lang die Queue entsprechend voll/lang ist. Auf dieses Signal hin wird ein zusätzlicher Worker eingerichtet (maximal einer pro Minute, damit eine kurzfristige Last nicht zum steigern der Worker führt).

[henfri]

Hallo,

verstehe.
Mir ist eingefallen, dass ich database_maxage bei vielen Items gesetzt haben.
Dann habe ich mal auf die Plugin-Scheduler geguckt:

database.Buffer dump	2022-04-24 10:02:28+0200	5	None	{60: 60}	-
database.Remove old	2022-04-24 10:03:30+0200	6	None	{91: 91}

Database dump... Schreibt das die Änderungen der DB auf die Platte? Dann wäre das ja normal, denke ich.
Remove old: Das hinzufügen von maxage ist eine Woche her. Danach hatte er natürlich erstmal viel zu tun. Aber innerhalb einer Woche sollte das doch erledigt sein, oder? Interessant: in meinen Logs (ein Logger ist auch Loglevel debug) finde ich kein remove_older.

Gruß,
Hendrik

 shng_details_file:
# This handler writes all entries to the details-file. Log entries with level WARNING
# and above are additionally written to the warnings-file (through the root logger).
#
# The TimedRotatingFileHandler seperates the logentries by day and
# keeps the entries of the last seven days in seperate files.
#
class: logging.handlers.TimedRotatingFileHandler
formatter: shng_simple
level: DEBUG
utc: false
when: midnight
backupCount: 7
filename: ./var/log/smarthome-details.log
encoding: utf8
filters: [knx_filter]

[Msinn]

Schreibt das die Änderungen der DB auf die Platte?

Ja, das sorgt dafür, dass Änderungen in die Datenbank geschrieben werden. Das database Plugin (wie auch schon vorher das sqlite Plugin) cacht ersmal eine Reihe von Änderungen, um sie dann "en-block" zu schreiben. Das dient der Lebensverlängerung von SD Karten.

Das bedeutet auch, dass die remove_older Tätigkeiten extem schnell fertig sind (sie arbeiten erstmal nur im RAM), weshalb Du davon auch nichts siehst. Das dumpen hingegen benötigt entsprechend Zeit in der Datenbank und ist daher eher ein Langläufer.

[henfri]

Hallo,

Das bedeutet auch, dass die remove_older Tätigkeiten extem schnell fertig sind (sie arbeiten erstmal nur im RAM), weshalb Du davon auch nichts siehst. Das dumpen hingegen benötigt entsprechend Zeit in der Datenbank und ist daher eher ein Langläufer.

Ok, aber wenigstens die log-einträge sollte ich doch sehen (klar, den Scheduler erwische ich vielleicht nicht).
Wie auch immer: Dem entnehme ich, dass es eher nicht am remove_old liegt?

Seit ich alle Plugins außer knx und database deaktiviert habe und 9GB swap spendiert habe, sieht es besser aus:
SH-NG1.png


Es werden die 30 Worker nicht mehr erreicht.
Neustarts gab es aber:

root@homeserver:~/smarthomeNGconfig/var/log# grep -i "SmartHomeNG initialization finished" smarthome-warnings.log
2022-04-24 06:52:12 NOTICE lib.smarthome -------------------- SmartHomeNG initialization finished --------------------
root@homeserver:~/smarthomeNGconfig/var/log# grep -i "SmartHomeNG initialization finished" smarthome-warnings.log.2022-04-23
2022-04-23 02:20:46 NOTICE lib.smarthome -------------------- SmartHomeNG initialization finished --------------------
2022-04-23 09:15:18 NOTICE lib.smarthome -------------------- SmartHomeNG initialization finished --------------------
2022-04-23 16:08:35 NOTICE lib.smarthome -------------------- SmartHomeNG initialization finished --------------------
2022-04-23 16:29:37 NOTICE lib.smarthome -------------------- SmartHomeNG initialization finished --------------------
2022-04-23 23:29:03 NOTICE lib.smarthome -------------------- SmartHomeNG initialization finished --------------------

Es gibt ja keine Einträge im Log, welche darauf hin weisen dass SH sich selbst beendet.
Sollte es diese nicht geben?
Kann es sein, dass SH extern (vom Kernel) beendet wird?

free -h
              total        used        free      shared  buff/cache   available
Mem:           11Gi       4,9Gi       481Mi       181Mi       6,2Gi       6,4Gi
Swap:           9Gi        83Mi       9,9Gi

Hinsichtlich des RAM-Verbrauchs sieht das aber alles eigentlich nicht wild aus:
SH-NG2.png

Vorallem korrelliert der Sprung in den Workern und Threads nicht mit der Ram-Nutzung.

Gruß,
Hendrik

[henfri]

Hallo,

ich habe jetzt das Database-Plugin deaktiviert und alle anderen aktiviert gelassen.
Seitdem habe ich keine weiteren Abstürze gehabt - natürlich funktionieren die Resourcen-Graphen nicht.
Auch gab es keine Meldungen mehr wie "Needing more worker threads than the specified maximum of 20! (20 worker threads active)"

Wie komme ich jetzt weiter?

Seit meinem letzten Commit in mein eigenes Git habe ich folgendes gemacht.

Neue logiken
Nachdimmen_Gaestebad:
Nachdimmen_Kinderbad:
Huehnerklappe:
telegram_bot:
Heizung_wieder_an:

Neue Plugins:
telegram
tasmota
fritzbox

alexarc4shng: Multifaktor
database_maxage

Gruß,
Hendrik

[Msinn]

Seitdem habe ich keine weiteren Abstürze gehabt

Es sind keine Abstürze!!! Die Neustarts werden von SmartHomeNG bewusst zur Sicherstellung der Lauffähigkeit ausgelöst.

[henfri]

Hm, sollte es dann nicht einen Log Eintrag geben, der das besagt?

Wie auch immer:
Wie finde ich den Grund für die zu vielen Worker?