js-controller 2 jetzt für alle im Stable
-
@marcuskl es kann immer noch passieren das Prozesse „hängenbleiben“. Die Erkennung und Behandlung der Fälle sollten aber besser laufen. Für den minim Auszug fehlt mir jetzt ein bissl Kontext.
-
@apollon77 Was soll ich noch raussuchen ?
-
Was hast du denn getan? Adapter restart im Admin oder wie? Läuft denn noch ein Radar2 Prozess mit de me genannten Prozess id?
Dann kill mal manuell. Mich wundert das der Radar2 im log nichts sagt ...
-
@apollon77 habe ich auch immer wider mit dem radar2.
Heute z.b. nachdem ich iobroker gestoppt hatte und einen snapshot zurück spielte. -
@apollon77 Ich habe was in der Adapterkonfiguration von radar geändert und danach startet der Adapter ja neu.
Prozesse finde ich nur eine Radar und de me nicht:root@iobroker:~# ps -e PID TTY TIME CMD 1 ? 00:00:02 systemd 2 ? 00:00:00 kthreadd 3 ? 00:00:00 ksoftirqd/0 5 ? 00:00:00 kworker/0:0H 6 ? 00:00:00 kworker/u4:0 7 ? 00:00:03 rcu_sched 8 ? 00:00:00 rcu_bh 9 ? 00:00:00 migration/0 10 ? 00:00:00 lru-add-drain 11 ? 00:00:00 watchdog/0 12 ? 00:00:00 cpuhp/0 13 ? 00:00:00 cpuhp/1 14 ? 00:00:00 watchdog/1 15 ? 00:00:00 migration/1 16 ? 00:00:00 ksoftirqd/1 18 ? 00:00:00 kworker/1:0H 19 ? 00:00:00 kdevtmpfs 20 ? 00:00:00 netns 21 ? 00:00:00 khungtaskd 22 ? 00:00:00 oom_reaper 23 ? 00:00:00 writeback 24 ? 00:00:00 kcompactd0 26 ? 00:00:00 ksmd 27 ? 00:00:00 khugepaged 28 ? 00:00:00 crypto 29 ? 00:00:00 kintegrityd 30 ? 00:00:00 bioset 31 ? 00:00:00 kblockd 32 ? 00:00:00 devfreq_wq 33 ? 00:00:00 watchdogd 35 ? 00:00:00 kswapd0 36 ? 00:00:00 vmstat 48 ? 00:00:00 kthrotld 49 ? 00:00:00 ipv6_addrconf 84 ? 00:00:00 bioset 85 ? 00:00:00 bioset 86 ? 00:00:00 bioset 87 ? 00:00:00 bioset 88 ? 00:00:00 bioset 89 ? 00:00:00 bioset 90 ? 00:00:00 bioset 91 ? 00:00:00 bioset 92 ? 00:00:00 kworker/u4:1 93 ? 00:00:00 ata_sff 94 ? 00:00:00 scsi_eh_0 95 ? 00:00:00 scsi_tmf_0 96 ? 00:00:00 scsi_eh_1 97 ? 00:00:00 scsi_tmf_1 99 ? 00:00:00 bioset 102 ? 00:00:00 scsi_eh_2 103 ? 00:00:00 scsi_tmf_2 104 ? 00:00:00 bioset 364 ? 00:00:00 kworker/0:1H 412 ? 00:00:00 jbd2/sda1-8 413 ? 00:00:00 ext4-rsv-conver 434 ? 00:00:00 kworker/1:1H 442 ? 00:00:00 systemd-journal 444 ? 00:00:00 kauditd 468 ? 00:00:00 systemd-udevd 490 ? 00:00:00 kworker/u5:1 516 ? 00:00:00 ttm_swap 613 ? 00:00:00 irqbalance 614 ? 00:00:00 rsyslogd 615 ? 00:00:00 bluetoothd 617 ? 00:00:00 cron 620 ? 00:00:00 dbus-daemon 638 ? 00:00:00 systemd-logind 639 ? 00:00:01 avahi-daemon 643 ? 00:00:00 sshd 650 ? 00:00:00 avahi-daemon 651 tty1 00:00:00 agetty 667 ? 00:00:00 systemd-timesyn 674 ? 00:00:00 dhclient 1953 ? 00:00:00 sshd 1955 ? 00:00:00 systemd 1956 ? 00:00:00 (sd-pam) 1962 pts/0 00:00:00 bash 2092 ? 00:07:00 iobroker.js-con 2111 ? 00:01:51 io.admin.0 2126 ? 00:01:30 io.javascript.0 2141 ? 00:00:06 io.info.0 2160 ? 00:01:14 io.iot.0 2317 ? 00:00:07 io.lgtv.0 2528 ? 00:00:06 io.web.0 2547 ? 00:00:11 io.sonoff.0 2562 ? 00:00:06 io.broadlink2.0 2577 ? 00:00:09 io.telegram.0 2607 ? 00:01:04 io.shelly.0 2626 ? 00:00:29 io.tr-064.0 2641 ? 00:00:05 io.sayit.0 2656 ? 00:00:09 io.upnp.0 2671 ? 00:00:09 io.simple-api.0 2686 ? 00:00:07 io.tankerkoenig 2697 ? 00:00:35 io.lovelace.0 2712 ? 00:00:34 io.proxmox.0 2727 ? 00:00:05 io.sayit.1 2746 ? 00:00:07 io.tuya.0 2761 ? 00:00:09 io.radar2.0 2793 ? 00:00:13 io.chromecast.0 2809 ? 00:00:08 io.influxdb.0 2844 ? 00:00:07 io.sourceanalyt 2863 ? 00:00:07 io.tankerkoenig 2963 ? 00:00:01 kworker/1:0 3284 ? 00:00:00 kworker/1:1 3290 ? 00:00:00 hci0 3291 ? 00:00:00 hci0 3292 ? 00:00:00 kworker/u5:2 3380 ? 00:00:00 sh <defunct> 3465 ? 00:00:09 io.zigbee.0 3476 ? 00:00:00 kworker/0:1 3682 ? 00:00:00 sshd 3688 pts/1 00:00:00 bash 3721 ? 00:00:00 kworker/0:0 3760 ? 00:00:00 kworker/u4:2 3779 ? 00:00:00 kworker/0:2 3786 pts/1 00:00:00 ps -
@marcuskl sagte in js-controller 2 jetzt für alle im Stable:
2761 ? 00:00:09 io.radar2.0
Da ist er aber
Kille den mal.
-
Scheinbar ist das Stable File nicht aktualisiert worden ... komisch. Aber die 2.1.0 sollte bald bei allen nach und nach auftauchen.
-
@apollon77 ja das habe ich ja gesagt, ich finde nur diesen einen und nicht 2.
Ich habe diesen auch schon gekillt, hat aber nichts geändert, beim start von Radar wieder das selbe Problem. -
@marcuskl dann starte bitte Radar2 mal im loglevel silly und lass kurz laufen und restarte dann mal. Dann poste mal das log
-
@apollon77 Habe jetzt das 2.1.0 Update gemacht.
Was mir schon bei 2.0.43 aufgefallen ist das der "Tuya" Adapter nicht mehr richtig arbeitet:host.ioBroker 2019-11-15 21:18:54.422 info "system.adapter.tuya.0" disabled tuya.0 2019-11-15 21:18:27.143 error (5662) 5303504684f3eb21724b: Error: connection timed out host.ioBroker 2019-11-15 21:18:19.403 info instance system.adapter.tuya.0 started with pid 5662Aber ich habe noch keine Gelegenheit gehabt um den Fehler näher einzugrenzen.
-
@apollon77
Vielen Dank, läuft problemlos auf 5 Clients und dem Host. Konnte alle problemlos updaten, ohne Fehlermeldungen.
71 Instanzen ohne Probleme... -
@marcuskl ALso ich kann es auch bei mir mit dem radar2 nachstellen. Irgendwie hängt der beim beenden und reagiert nicht auf einen kill. Andere Adapter machen das wie Sie sollen. Leg bitte dazu mal ein issue beim Adapter an. Muss sich der Dev ansehen
-
@Chaot Was genau ist denn der Fehler? Das "connection timed out"? Dann kann er keine Verbindung zu dem Gerät herstellen ... wüsste nicht was das mit dem controller zu tun hat.Mach ggf mal das Gerät Stromlos und restarte es
-
Bei mir hing gerade der radar2 Adapter und ein Skripte welches auf das Objekt system.adapter.radar2.0.connected hört warf den Fehler dass das Objekt nicht existiert.
2019-11-15 21:24:00.014 - [33mwarn[39m: javascript.0 (27906) getState "system.adapter.radar2.0.connected" not found (3)Es ist zwar da war aber wertelos. Bis JS-Controller 1.5 waren alive und connected immer ausnahmslos entweder true oder fase, aber nicht leer. Und wieso sagt das Log not found obwohl das Objekt vorhanden ist?
Edit: Es gab einen Zombiprozess der mit pkill nicht zu töten war.
diginix@host:/opt/iobroker/log$ sudo pkill -f io.radar2.0 diginix@host:/opt/iobroker/log$ ps aux | grep radar iobroker 457 0.0 2.1 824208 85064 ? Sl 19:34 0:06 io.radar2.0Nur mit kill -9 457 konnte ich ihn beenden.
-
@Diginix alive und connected werden mit einem "expire" von glaube ca. 30s auf "true" gesetzt während der Adapter läuft. Normalerweise wird der Wert alle 15s neu gesetzt und damit bleibt er "true". Wenn Adapter gestoppt setzt der Controller auf false ohne expire.
Falls der Adapter jetzt hängenbleibt und damit der Wert "expired" wird der State auf null gesetzt und ist Wert-los ... genau das meckert JavaScript in dem Fall ggf an.
In controller 1.5 wurde bei einem expire (und file DB) nicht der State gelöscht sondern der Wert auf "null" (für dich dann auch false) gesetzt. Bei redis DB aber gelöscht wie jetzt. Mit js.controller 2 ziehen wir das gleich.
-
Hm, ok dann muss ich mal schauen was ich am Skript ändern kann.
Aktuell habe ich andauern ein Zombie vom radar2 v1.2.0 (mit gepatchter myAdapter.js).
Lief mit JS-Controller 1.5.14 monatelang stabil. Hoffe das fängt sich wieder mit 2.x. -
@Diginix Es kann sehr gut sein das in der myAdapter Lib von Frank noch irgendwo was drin steckt was bisher keinen Fehler wirft aber solche hänger verursacht ... Hoffen wir mal das Frank bald wieder zeit findet. leg doch bitte ein Issue an mit so vielen Infos wie es geht
-
@apollon77 Ok habe ich gemacht.
-
Bei mir lief die Installation ohne Fehler durch.
Jetzt komme ich bis zur Anmeldeseite und kann mich mit meinem Namen und Passwort nicht mehr anmelden.
Muss ich etwa was anderes eingeben? -
Aarg!
simple-api wirft nun einen {"error":"permissionError"} bei den Aufrufen die bis vor dem Update problemlos funktionierten.
Was hat sich da denn geändert?
