UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[leif1]

@homoran said in [Gelöst]no connection to database:

und welche Versiuon hast du da jetzt?

JS Controller 3.2.16 hab ich aktuell installiert.

(Umgebung ist nen Pi4 mit Buster)

[Thomas Braun]

@leif1
Mach mal eine Konsole auf und beobachte

dmesg -wT

Dann in einer zweiten Konsole:

iobroker stop
iobroker update
iobroker upgrade
iobroker upgrade self
iobroker start

Passiert in der ersten Konsole währenddessen was?

Wenn nichts passiert, das gleiche Spiel nochmal mit

iobroker logs --watch

in der ersten Konsole.

[leif1]

@thomas-braun

Dort taucht bei mir in beiden Fällen gar nichts auf, weder bei dmesg -wT noch bei iobroker logs --watch.

Allerdings melden mehrere Adapter während der ioBroker aktiv ist

2021-08-26 20:01:36.686  - warn: info.0 (3195) slow connection to states DB. Still waiting ...

Zudem ist mir aufgefallen dass meine Influx DB für Grafana auch nicht mehr erreichbar ist.

[Thomas Braun]

@leif1

Keine Ahnung warum da die I/O-Last offenbar so hoch ist.
Unnötiger Krempel am Start? Desktop-Umgebung? Remote-Desktop gar?

[LausiD]

Problem mit no conection to database hatte ich auch mal.....
Abhilfe schaffte folgender Vorschlag von apollon77 :-)

apollon77

1. Mai 2021, 23:38

@lausid Also das passiert an sich nur wenn die SD oder platte eccht beschäftigt ist oder die Kiste und die DB Verbindung zu lange dauert (2s sind eingestellt).

Dann auf die Harte tour:
Editiere /opt/iobroker/iobroker-data/iobroker.json

und unter objects und states bigs ein

"connectTimeout": 2000,

mach mal 5000 draus.

Gruß LausiD

[Thomas Braun]

@lausid Wobei man mal schauen sollte, was da für soviel Verkehr auf dem Bus sorgt das es sich da staut.

[leif1]

@thomas-braun
Ist nen Pi4 mit 4GB Ram und Raspbian Buster ohne Desktop. Außer ioBroker, Grafana und InfluxDB läuft nichts drauf.
Könnte mir höchstens vorstellen dass die SD Karte schlapp macht, ist nur komisch dass es nun direkt nach den Updates auftaucht und Nutzer wie Chaos offenbar das gleiche Problem haben.

[Thomas Braun]

@leif1

htop

oder

top

liefern?

[leif1]

@lausid
Danke, nun tut sich was. :+1:

@Thomas-Braun liefere ich gleich nach sobald ich durch bin.

edit: zu früh gefreut. Nachdem nun iobroker upgrade & iobroker upgrade self ohne db fehler anlief kommt nun im Verlauf des versuchten JS Controller upgrades

pi@raspi4:~ $ iobroker upgrade self
Update js-controller from @3.2.16 to @3.3.15
NPM version: 6.14.14
npm install iobroker.js-controller@3.3.15 --loglevel error --unsafe-perm --prefi                      x "/opt/iobroker" (System call)
 Objects database error: connect ECONNREFUSED 127.0.0.1:9001
 States database error: connect ECONNREFUSED 127.0.0.1:9000

[leif1]

@thomas-braun

mein "top"

top - 21:29:08 up  1:33,  3 users,  load average: 2,27, 2,70, 3,25
Tasks: 134 total,   1 running, 133 sleeping,   0 stopped,   0 zombie
%Cpu(s): 32,5 us,  2,1 sy,  0,0 ni, 65,4 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
MiB Mem :   3838,7 total,   2883,8 free,    187,7 used,    767,2 buff/cache
MiB Swap:    100,0 total,    100,0 free,      0,0 used.   3465,4 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
27611 influxdb  20   0  944900  78732  41216 S 128,1   2,0   0:09.25 influxd
27522 pi        20   0   10332   2980   2436 R   1,0   0,1   0:00.25 top
   12 root      20   0       0      0      0 I   0,3   0,0   0:12.89 rcu_sched
  594 mysql     20   0  723752  66628  15324 S   0,3   1,7   0:13.93 mysqld
27610 influxdb  20   0    7808   2664   2488 S   0,3   0,1   0:00.04 influxd-systemd
    1 root      20   0   32712   8084   6468 S   0,0   0,2   0:17.56 systemd
    2 root      20   0       0      0      0 S   0,0   0,0   0:00.03 kthreadd
    3 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 rcu_gp
    4 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 rcu_par_gp
    8 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 mm_percpu_wq
    9 root      20   0       0      0      0 S   0,0   0,0   0:00.00 rcu_tasks_rude_
   10 root      20   0       0      0      0 S   0,0   0,0   0:00.00 rcu_tasks_trace
   11 root      20   0       0      0      0 S   0,0   0,0   0:07.88 ksoftirqd/0
   13 root      rt   0       0      0      0 S   0,0   0,0   0:00.74 migration/0
   14 root      20   0       0      0      0 S   0,0   0,0   0:00.00 cpuhp/0
   15 root      20   0       0      0      0 S   0,0   0,0   0:00.00 cpuhp/1
   16 root      rt   0       0      0      0 S   0,0   0,0   0:00.72 migration/1
   17 root      20   0       0      0      0 S   0,0   0,0   0:02.24 ksoftirqd/1
   20 root      20   0       0      0      0 S   0,0   0,0   0:00.00 cpuhp/2
   21 root      rt   0       0      0      0 S   0,0   0,0   0:00.64 migration/2
   22 root      20   0       0      0      0 S   0,0   0,0   0:02.44 ksoftirqd/2
   25 root      20   0       0      0      0 S   0,0   0,0   0:00.00 cpuhp/3
   26 root      rt   0       0      0      0 S   0,0   0,0   0:00.58 migration/3
   27 root      20   0       0      0      0 S   0,0   0,0   0:02.44 ksoftirqd/3
   29 root       0 -20       0      0      0 I   0,0   0,0   0:08.48 kworker/3:0H-kblockd
   30 root      20   0       0      0      0 S   0,0   0,0   0:00.00 kdevtmpfs
   31 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 netns
   34 root      20   0       0      0      0 S   0,0   0,0   0:00.00 kauditd
   36 root      20   0       0      0      0 S   0,0   0,0   0:00.00 khungtaskd
   37 root      20   0       0      0      0 S   0,0   0,0   0:00.00 oom_reaper
   38 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 writeback
   39 root      20   0       0      0      0 S   0,0   0,0   0:00.58 kcompactd0
   57 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 kblockd
   58 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 blkcg_punt_bio
   59 root     -51   0       0      0      0 S   0,0   0,0   0:00.00 watchdogd
   62 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 rpciod
   63 root       0 -20       0      0      0 I   0,0   0,0   0:00.05 kworker/u9:0-hci0
   64 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 xprtiod
   65 root      20   0       0      0      0 S   0,0   0,0   0:00.00 kswapd0
   66 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 nfsiod
   67 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 kthrotld
   68 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 iscsi_eh
   69 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 iscsi_destroy
   70 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 nvme-wq
   71 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 nvme-reset-wq
   72 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 nvme-delete-wq
   76 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 DWC Notificatio
   77 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 uas

Die CPU Usage der InfluxDB ist nicht normal oder? Wobei er extrem zwischen 10 und 120% schwankt

Werde es mal stoppen und nochmals versuchen.

[Thomas Braun]

@leif1 Nee...
Leg die mal auf Eis. Mindestens während des upgrades.

[leif1]

@thomas-braun

Nochmals vielen Dank für die Hilfe - nun läuft wieder alles.

Ein kleiner Nachtrag in der Hoffnung dass er vielleicht auch @chaos99 helfen könnte:

In meinem Fall war die Hauptursache wohl wirklich InfluxDB. Zunächst bekam ich dies auch nicht mehr ans laufen, bis ich folgenden Beitrag mit Problemen zu relativ frischen InfluxDB Versionen fand
link text

Ein erhöhen des Sleep von 1 auf 10 im InfluxDB Startscript löste dann auch das Problem, auch wenn das sicherlich keine ideale Lösung sein mag und der Fehler wohl irgendwo in den jüngsten InfluxDB Versionen liegt.