js-controller 2 jetzt für alle im Stable

sigi234

Unter Windows aber noch nicht möglich?
Im Installer noch nicht drinnen.

marcuskl

Sollte das hier eigentlich nicht Vergangenheit sein ?

host.iobroker	2019-11-15 19:35:25.343	warn	instance system.adapter.radar2.0 already running with pid 2761
host.iobroker	2019-11-15 19:35:23.840	info	stopInstance system.adapter.radar2.0 killing pid 2761
host.iobroker	2019-11-15 19:35:22.840	info	stopInstance system.adapter.radar2.0 send kill signal
host.iobroker	2019-11-15 19:35:22.838	info	stopInstance system.adapter.radar2.0 (force=false, process=true)
host.iobroker	2019-11-15 19:35:22.837	info	"system.adapter.radar2.0" enabled
host.iobroker	2019-11-15 19:35:22.218	info	stopInstance system.adapter.radar2.0 killing pid 2761
host.iobroker	2019-11-15 19:35:21.217	info	stopInstance system.adapter.radar2.0 send kill signal
host.iobroker	2019-11-15 19:35:21.215	info	stopInstance system.adapter.radar2.0 (force=false, process=true)
host.iobroker	2019-11-15 19:35:21.212	info	"system.adapter.radar2.0" disabled

apollon77

@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.

marcuskl

@apollon77 Was soll ich noch raussuchen ?

apollon77

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 ...

crunchip

@apollon77 habe ich auch immer wider mit dem radar2.
Heute z.b. nachdem ich iobroker gestoppt hatte und einen snapshot zurück spielte.

marcuskl

@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

apollon77

@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.

apollon77

Scheinbar ist das Stable File nicht aktualisiert worden ... komisch. Aber die 2.1.0 sollte bald bei allen nach und nach auftauchen.

marcuskl

@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.

apollon77

@marcuskl dann starte bitte Radar2 mal im loglevel silly und lass kurz laufen und restarte dann mal. Dann poste mal das log

Chaot

@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 5662

Aber 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...

apollon77

@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

apollon77

@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

Diginix

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.0

Nur mit kill -9 457 konnte ich ihn beenden.

apollon77

@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.

Diginix

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.

apollon77

@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

marcuskl

@apollon77 Ok habe ich gemacht.

NEWS

js-controller 2 jetzt für alle im Stable

Support us

589
Online

31.9k
Users

80.1k
Topics

1.3m
Posts

NEWS

js-controller 2 jetzt für alle im Stable

Support us

589Online

31.9kUsers

80.1kTopics

1.3mPosts

589
Online

31.9k
Users

80.1k
Topics

1.3m
Posts