NEWS
UNSOLVED Absturz jede Nacht - ECONNRESET - ECONNREFUSED
-
@Thomas-Braun
AH Danke. Sehe gerade dass Redis mir folgendes meldet:7908:M 07 Jul 08:48:04.146 # Background saving error 7908:M 07 Jul 08:48:10.062 * 100 changes in 300 seconds. Saving... 7908:M 07 Jul 08:48:10.063 * Background saving started by pid 19857 19857:C 07 Jul 08:48:10.063 # Failed opening the RDB file dump.rdb (in server root dir /etc/redis) for saving: Permission denied
-
Das ständig mit einer neuen PID
-
@besa Alles krumm aufgesetzt, scheint mir.
Aber ohne Konsolenrückmeldung keine Hilfe möglich. Viel Spaß noch, ich bin dann raus.
-
@Thomas-Braun
Sorry
Hier die Rückmeldunglinaro@tinkerboard:/etc/redis$ uname -a Linux tinkerboard 4.4.132+ #1 SMP Wed Aug 21 19:15:55 CST 2019 armv7l GNU/Linux linaro@tinkerboard:/etc/redis$ who -r Runlevel 5 2020-07-07 08:19 linaro@tinkerboard:/etc/redis$
-
setze mal deine kopierten Zeilen von der Konsole in Code tags </> diese Symbol anklicken und dazwischen einfügen
dann ercheint in der Antwort diese Fensterhier steht dann dein Text
-
linaro@tinkerboard:/etc/redis$ uname -a Linux tinkerboard 4.4.132+ #1 SMP Wed Aug 21 19:15:55 CST 2019 armv7l GNU/Linux
linaro@tinkerboard:/etc/redis$ who -r Runlevel 5 2020-07-07 08:19
-
@besa
guck mal hier, da hat @Thomas-Braun mir mal erklärt, das der Runlevel 5 nicht gut für ein Server ist. Vielleicht solltest du den mal auf Level 3 ändern, weiß aber nicht ob die Befehle die gleichen sind.https://forum.iobroker.net/topic/33702/iobroker-startet-sporadisch-neu/20
da kann @Thomas-Braun dir bestimmt weiterhelfen
-
Gemäß der Anleitung von Thomas- Braun habe ich auf Runlevel 3 umgestellt
sudo whoami systemctl get-default sudo systemctl set-default multi-user.target systemctl get-default
und dann
sudo reboot
Dann
linaro@tinkerboard:/opt/iobroker$ who -r Runlevel 3 2020-07-07 09:30
Ergebnis: IOBROKER läuft nicht mehr.
-
dann den Redis Server manuell gestartet mit
redis-server
IOBROKER läuft wieder !!!!!!!!!
aber Redis gibt folgende Meldungen aus
6122:C 07 Jul 09:40:36.703 # Warning: no config file specified, using the default config. In order to specify a config file use redis-server /path/to/redis.conf 6122:M 07 Jul 09:40:36.704 * Increased maximum number of open files to 10032 (it was originally set to 1024). 6122:M 07 Jul 09:40:36.705 # Warning: 32 bit instance detected but no memory limit set. Setting 3 GB maxmemory limit with 'noeviction' policy now. _._ _.-``__ ''-._ _.-`` `. `_. ''-._ Redis 3.2.6 (00000000/0) 32 bit .-`` .-```. ```\/ _.,_ ''-._ ( ' , .-` | `, ) Running in standalone mode |`-._`-...-` __...-.``-._|'` _.-'| Port: 6379 | `-._ `._ / _.-' | PID: 6122 `-._ `-._ `-./ _.-' _.-' |`-._`-._ `-.__.-' _.-'_.-'| | `-._`-._ _.-'_.-' | http://redis.io `-._ `-._`-.__.-'_.-' _.-' |`-._`-._ `-.__.-' _.-'_.-'| | `-._`-._ _.-'_.-' | `-._ `-._`-.__.-'_.-' _.-' `-._ `-.__.-' _.-' `-._ _.-' `-.__.-' 6122:M 07 Jul 09:40:36.706 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128. 6122:M 07 Jul 09:40:36.706 # Server started, Redis version 3.2.6 6122:M 07 Jul 09:40:36.706 * The server is now ready to accept connections on port 6379 ^C6122:signal-handler (1594107715) Received SIGINT scheduling shutdown... 6122:M 07 Jul 09:41:55.917 # User requested shutdown... 6122:M 07 Jul 09:41:55.917 * Saving the final RDB snapshot before exiting. 6122:M 07 Jul 09:41:55.955 * DB saved on disk 6122:M 07 Jul 09:41:55.955 # Redis is now ready to exit, bye bye...
-
@besa
und schmiert beim laden der Instanzen ab........ -
@besa
und kommt dann wieder. Sowas. -
So ich dokumentiere einmal den letzten Stand. Irgendwie hat sich der REDIS Server anscheinend in der Nacht verabschiedet. Ich habe daher folgendes gemacht
Gem Rat von Thomas Braun hatte ich auf Runlevel 5 umgestellt. Aufruf von TOP ergibt jetzt:
top - 16:42:06 up 4:41, 1 user, load average: 1,31, 1,37, 1,36 Tasks: 171 total, 2 running, 165 sleeping, 0 stopped, 4 zombie %Cpu(s): 6,7 us, 28,0 sy, 0,0 ni, 65,0 id, 0,0 wa, 0,0 hi, 0,3 si, 0,0 st KiB Mem : 2060400 total, 844668 free, 887164 used, 328568 buff/cache KiB Swap: 102396 total, 102396 free, 0 used. 1142028 avail Mem
Ich hatte weiterhin den Redis Server deinstalliert mit
sudo apt-get purge --auto-remove redis-server
Dann gemäß der Anleitung unter
how-to-install-and-secure-redis-on-ubuntu-18-04Hier die Kurzversion
sudo apt update sudo apt install redis-server
den Redis-Server neuinstalliert. Dann noch die Dateirechte geändert
sudo chmod -R -v 777 /etc/redis
und in redis.conf mit
sudo nano /etc/redis/redis.conf
bind 0.0.0.0
supervised systemd
protected-mode yes (unverändert)ergänzt.
Dauerhaften Start eingetragen mit
sudo systemctl restart redis.service
Redis überprüft mit
sudo systemctl status redis $ redis-cli ping PONG
und ein Reboot durchgeführt. Dann musste ich nochmals das MULTIHOST system mit
iobroker stop sudo iobroker multihost enable
inkl. Passwort Eingabe initialisieren. Jetzt läuft alles und ich bin gespannt ob es auch über Nacht so bleibt. Falls ja werde ich es ergänzen oder morgen hier heulen.
Danke und Viele Grüße
Bernd
-
Meinte auf RUN-Level 3 umgestellt.
-
@besa
Die 4 Zombies da im Eck sehen auch nicht so ganz gesund aus.chmod 777 rekursiv auf /etc/redis ist auch Quatsch. Richtig sieht es so aus:
pi@raspberrypi:~$ ls -la /etc/redis/ insgesamt 72 drwxr-xr-x 2 root root 4096 Jun 4 00:16 . drwxr-xr-x 100 root root 4096 Jul 1 21:55 .. -rw-r----- 1 redis redis 62241 Jun 4 00:16 redis.conf pi@raspberrypi:~$
-
*** Hat funktioniert ***
Alles läuft wieder wie es sein soll. Wenn ich hier noch was als gelöst kennzeichnen soll, bin ich für jeden Tip dankbar.
Viele Grüße Bernd
-
Danke für den Hinweis. Ich werde die Rechte anpassen. Das war ein schneller Fix, da ich ja gesehen hatte, dass REDIS das dump.rdb nicht schreiben konnte.
Was ich mit den zombie mache ich mir noch nicht ganz klar. Werde ich mal googeln. Danke.
-
Rechte haben ich korrigiert mit
sudo chmod 755 /etc sudo chmod 755 /etc/redis
Danke und viele Grüße Bernd
-
Leider schmiert IOBROKER wieder ab. Ich finde im LOG keinen Fehler und bin ratlos.
-
2020-07-09 22:55:05.557 - [33mwarn[39m: host.tinkerboard instance system.adapter.admin.0 terminated due to SIGKILL 2020-07-09 22:55:05.567 - [32minfo[39m: host.tinkerboard instance system.adapter.admin.0 terminated with code NaN () 2020-07-09 22:55:05.568 - [32minfo[39m: host.tinkerboard Restart adapter system.adapter.admin.0 because enabled
Hat das eine Beduetung. Warum wird der admin Adapter gekilled ? Kam warscheinlich vom restart. Man wird ja komplett durcheinander.