UPGRADE IP 9 verfügbar!
Timberwolf VISU jetzt mit NEUEM Layout Editor
Freie Anordnung, Reihenfolge und Größe der Widgets - viele weitere Verbesserungen
Infos im Wiki: https://elabnet.atlassian.net/l/cp/06SeuHRJ

NEU! Insider & Leistungsmerkmale FÜR ALLE freigeschaltet
Damit kann nun jeder das Upgrade vornehmen und VISU & IFTTT testen. Alle Info hier: viewtopic.php?f=8&t=5074

[Problem] Werkseinstellung bei rescue

Alles was sonst irgendwie nirgends rein passt.
Forumsregeln
  • Denke bitte an aussagekräftige Titel und gebe dort auch die [Firmware] an. Wenn ETS oder CometVisu beteiligt sind, dann auch deren Version
  • Bitte mache vollständige Angaben zu Deinem Server, dessen ID und dem Online-Status in Deiner Signatur. Hilfreich ist oft auch die Beschreibung der angeschlossener Hardware sowie die verwendeten Protokolle
  • Beschreibe Dein Projekt und Dein Problem bitte vollständig. Achte bitte darauf, dass auf Screenshots die Statusleiste sichtbar ist
  • Bitte sei stets freundlich und wohlwollend, bleibe beim Thema und unterschreibe mit deinem Vornamen. Bitte lese alle Regeln, die Du hier findest: https://wiki.timberwolf.io/Forenregeln

Ersteller
murelli146
Reactions:
Beiträge: 90
Registriert: Mi Jan 16, 2019 9:21 pm
Hat sich bedankt: 13 Mal
Danksagung erhalten: 50 Mal

#11

Beitrag von murelli146 »

Matthias hat mein Problem auf meinen Container knxdmxdocker zurückführen können.

Nochmal die Reihenfolge wie es zu diesem Problem kam:
1. macvlan erstellt
2. ssh und knxdmxddocker konfiguriert (mit macvlan verbunden)
3. ssh Container OK > zugriff auf knxdmxdocker OK
4. Problem eibd (Wiregate) nicht erreichbar.
5. Glorreiche Idee: macvlan löschen und neu erstellen
6. macvlan gelöscht
7. TWS und Portainer nicht mehr erreichbar
8. kann ich nicht mehr genau sagen: Neustart über Taster
9. Dann nur mehr rescue mode

Problem: "Aus mir nicht bekannten Gründen, verbraucht dieser Container alle Filedeskriptoren auf den System und macht jede Netzwerkkommunikation unmöglich."

Jetzt möchte ich das Problem in meiner Entwicklungsumgebung untersuchen. (VM)
In meiner Entwicklungsumgebung verhält sich der Container unauffällig > er funktioniert ;)
Wie kann ich den "Verbrauch der Filedeskriptoren" untersuchen bzw. Sichtbar machen? :confusion-helpsign:

Kann man wirklich durch löschen eines Netzwerks den Server lahm legen?
Macht es in meinem Fall die Kombination aus meinem Container und das löschen des macvlan aus?

Schöne Grüße
Gernot
Schöne Grüße
Gernot
_______________________________________________________
TWS 2600 ID:276 , VPN offen, Reboot nach Rücksprache erlaubt

ms20de
Elaborated Networks
Reactions:
Beiträge: 974
Registriert: Sa Aug 11, 2018 9:14 pm
Hat sich bedankt: 280 Mal
Danksagung erhalten: 499 Mal

#12

Beitrag von ms20de »

murelli146 hat geschrieben: Fr Mär 01, 2019 8:16 pm Wie kann ich den "Verbrauch der Filedeskriptoren" untersuchen bzw. Sichtbar machen? :confusion-helpsign:
lsof ist dein Freund.
https://www.cyberciti.biz/tips/linux-pr ... ptors.html
http://www.linux-community.de/ausgaben/ ... ne-tueren/

Werden irgendwo im knxdmxd viele Netzwerkverbindungen aufgebaut? Vielleicht wenn der den eibd nicht erreichen kann?
murelli146 hat geschrieben: Fr Mär 01, 2019 8:16 pm Kann man wirklich durch löschen eines Netzwerks den Server lahm legen?
Macht es in meinem Fall die Kombination aus meinem Container und das löschen des macvlan aus?
Ich glaube das war nicht das Problem.

Viele Grüße,
Matthias
[ Timberwolf Entwicklung ]

TWS 2400 ID:102 VPN offen, Reboot auf Nachfrage

Ersteller
murelli146
Reactions:
Beiträge: 90
Registriert: Mi Jan 16, 2019 9:21 pm
Hat sich bedankt: 13 Mal
Danksagung erhalten: 50 Mal

#13

Beitrag von murelli146 »

Habe mal in der VM getestet.

einmal eibd erreichbar:

Code: Alles auswählen

root@knxdmxd-vm:~# pidof knxdmxd
8072
root@knxdmxd-vm:~# lsof -p 8072
COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF   NODE NAME
knxdmxd 8072 root  cwd    DIR   0,37     4096  32710 /
knxdmxd 8072 root  rtd    DIR   0,37     4096  32710 /
knxdmxd 8072 root  txt    REG    8,1    39560 917733 /usr/bin/knxdmxd
knxdmxd 8072 root  mem    REG    8,1          788833 /usr/lib/x86_64-linux-gnu/libc-2.28.so (stat: No such file or directory)
knxdmxd 8072 root  mem    REG    8,1          788949 /usr/lib/x86_64-linux-gnu/libuuid.so.1.3.0 (stat: No such file or directory)
knxdmxd 8072 root  mem    REG    8,1          788915 /usr/lib/x86_64-linux-gnu/libpthread-2.28.so (stat: No such file or directory)
knxdmxd 8072 root  mem    REG    8,1          917737 /usr/local/lib/libeibclient.so.0.0.0 (path inode=4996)
knxdmxd 8072 root  mem    REG    8,1          917741 /usr/local/lib/libjson-c.so.4.0.0 (path inode=4985)
knxdmxd 8072 root  mem    REG    8,1          788811 /usr/lib/x86_64-linux-gnu/ld-2.28.so (stat: No such file or directory)
knxdmxd 8072 root    0r   CHR    1,3      0t0 122350 /dev/null
knxdmxd 8072 root    1w   CHR    1,3      0t0 122350 /dev/null
knxdmxd 8072 root    2w   CHR    1,3      0t0 122350 /dev/null
knxdmxd 8072 root    3u   REG    8,1        2 917551 /run/knxdmxd.pid
knxdmxd 8072 root    4u  sock    0,8      0t0 123168 protocol: UDP
knxdmxd 8072 root    5u  sock    0,8      0t0 123169 protocol: TCP
root@knxdmxd-vm:~# lsof -p 8072
eibd nicht erreichbar (falsche IP):

Code: Alles auswählen

root@knxdmxd-vm:~# pidof knxdmxd
11931
root@knxdmxd-vm:~# lsof -p 11931
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF   NODE NAME
knxdmxd 11931 root  cwd    DIR   0,37     4096 140157 /
knxdmxd 11931 root  rtd    DIR   0,37     4096 140157 /
knxdmxd 11931 root  txt    REG    8,1    39560 917733 /usr/bin/knxdmxd
knxdmxd 11931 root  mem    REG    8,1          788833 /usr/lib/x86_64-linux-gnu/libc-2.28.so (stat: No such file or directory)
knxdmxd 11931 root  mem    REG    8,1          788949 /usr/lib/x86_64-linux-gnu/libuuid.so.1.3.0 (stat: No such file or directory)
knxdmxd 11931 root  mem    REG    8,1          788915 /usr/lib/x86_64-linux-gnu/libpthread-2.28.so (stat: No such file or directory)
knxdmxd 11931 root  mem    REG    8,1          917737 /usr/local/lib/libeibclient.so.0.0.0 (path inode=4996)
knxdmxd 11931 root  mem    REG    8,1          917741 /usr/local/lib/libjson-c.so.4.0.0 (path inode=4985)
knxdmxd 11931 root  mem    REG    8,1          788811 /usr/lib/x86_64-linux-gnu/ld-2.28.so (stat: No such file or directory)
knxdmxd 11931 root    0r   CHR    1,3      0t0 140469 /dev/null
knxdmxd 11931 root    1w   CHR    1,3      0t0 140469 /dev/null
knxdmxd 11931 root    2w   CHR    1,3      0t0 140469 /dev/null
knxdmxd 11931 root    3u   REG    8,1        2 917608 /run/knxdmxd.pid
knxdmxd 11931 root    4u  sock    0,8      0t0 140281 protocol: UDP
root@knxdmxd-vm:~# root@knxdmxd-vm:~# pidof knxdmxd
Kann man daraus etwas schließen? Es ändert sich auch nach 5 Minuten betrieb nichts an dieser Ausgabe.

Hinzugefügt nach 38 Minuten 18 Sekunden:
Habe nun versucht den Fehler nachzustellen und mein macvlan gelöscht

In meiner VM lässt es sich nicht über Portainer löschen, was aber auf dem TWS möglich war bzw. eine Reihe von Fehlen auslöste bis zur nicht Erreichbarkeit.

Folgende Ausgabe auf der VM beim löschen:

Code: Alles auswählen

Failure
error while removing network: network macvlan0 id a634af88eb64dcbdd9ae328fabd1bbb7c7b9acbc35b0c3217c2a95cbec1cdce6 has active endpoints
Schöne Grüße
Gernot
_______________________________________________________
TWS 2600 ID:276 , VPN offen, Reboot nach Rücksprache erlaubt

ms20de
Elaborated Networks
Reactions:
Beiträge: 974
Registriert: Sa Aug 11, 2018 9:14 pm
Hat sich bedankt: 280 Mal
Danksagung erhalten: 499 Mal

#14

Beitrag von ms20de »

Bei den Ausgaben von lsof sehe ich kein Problem.
Vielleicht passiert es tatsächlich wenn man dem Container das Netzwerk wegnimmt, wie du meinst.

Habe zum Testen den knxdmxdocker auf meinem Test-Timberwolf installiert. Mit dem Standard-Bridge-Netzwerk bekomme ich den Fehler nicht.
Ich weiß allerdings auch nicht ob er sich über KNX-IP verbunden hat, was ich glaube das im Bridge-Netwerk nicht geht.

MACVLAN kann nicht gerade nicht testen, da mein Arbeits-VPN anscheinend das Wochenende für Erholung hart umsetzt und ich nur Akustikkoppler-Geschwindigkeit bekomme. :confusion-waiting:

Viele Grüße,
Matthias
[ Timberwolf Entwicklung ]

TWS 2400 ID:102 VPN offen, Reboot auf Nachfrage

Ersteller
murelli146
Reactions:
Beiträge: 90
Registriert: Mi Jan 16, 2019 9:21 pm
Hat sich bedankt: 13 Mal
Danksagung erhalten: 50 Mal

#15

Beitrag von murelli146 »

Habe den knxdmxdocker heute für ca. 8h im Echt-betrieb über die VM betrieben.
Scheint zu funktionieren.Habe ihn heute noch etwas überarbeitet.

Falls das beim TWS nochmal passiert kommt ihr über vpn noch drauf oder muss ich ihn einschicken?
ms20de hat geschrieben: Sa Mär 02, 2019 4:16 pm Akustikkoppler-Geschwindigkeit
:lol:

Na dann würde ich aber gleich mal anfangen das WE zu genießen und die Arbeit sein lassen.

Schöne Grüße
Gernot
Schöne Grüße
Gernot
_______________________________________________________
TWS 2600 ID:276 , VPN offen, Reboot nach Rücksprache erlaubt

Ersteller
murelli146
Reactions:
Beiträge: 90
Registriert: Mi Jan 16, 2019 9:21 pm
Hat sich bedankt: 13 Mal
Danksagung erhalten: 50 Mal

#16

Beitrag von murelli146 »

Damit ich mich hemmungslos dem Docker widmen kann bitte um Beantwortung folgender Frage.

Falls das beim TWS nochmal passiert kommt ihr über vpn noch drauf oder muss ich ihn einschicken?

Schöne Grüße
Gernot
Schöne Grüße
Gernot
_______________________________________________________
TWS 2600 ID:276 , VPN offen, Reboot nach Rücksprache erlaubt

StefanW
Elaborated Networks
Reactions:
Beiträge: 9689
Registriert: So Aug 12, 2018 9:27 am
Wohnort: Frauenneuharting
Hat sich bedankt: 4831 Mal
Danksagung erhalten: 7633 Mal
Kontaktdaten:

#17

Beitrag von StefanW »

Hallo Gernot,
murelli146 hat geschrieben: Di Mär 05, 2019 4:55 pmFalls das beim TWS nochmal passiert kommt ihr über vpn noch drauf oder muss ich ihn einschicken?
das kann man nicht pauschal beantworten. Eigentlich schaffen wir bisher alles Remote, wird nur beliebig aufwändig bzw. bedarf auch eines seriellen Console-Kabels.

Per Rescue-VPN kommen wir nur drauf, wenn die IP-Konfig per DHCP auf ETH0 verteilt wird.

(Wir haben aber überlegt, dass wir - künftig - für solche Fälle downloadbare Images für USB-Sticks anbieten, die gewisse Rücksetzaufgaben ausführen können, ist aber nur Planung bisher).

lg

Stefan
Stefan Werner
Product Owner für Timberwolf Server, 1-Wire und BlitzART
Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Zu Preisen, Lizenzen, Garantie, HW-Defekt an service at elabnet dot de

Link zu Impressum und Datenschutzerklärung oben.

Ersteller
murelli146
Reactions:
Beiträge: 90
Registriert: Mi Jan 16, 2019 9:21 pm
Hat sich bedankt: 13 Mal
Danksagung erhalten: 50 Mal

#18

Beitrag von murelli146 »

Zu tote gefürchtet ist auch gestorben.

Habe den Container "knxdmxdocker" in Betrieb genommen. Zuvor habe ich alles im Portainer gelöscht und neu angefangen.
Ich denke der Container bzw das img ist in Ordnung, es war vermutlich das im Betrieb gelöschten macvlan's.

Habe in meiner Entwicklungsumgebung Portainer 1.20.1 dort ist das löschen des macvlans im Betrieb nicht möglich.
Auf dem TWS Portainer v1.17.1 möchte ich das nicht testen.

Denke das hat sich erledigt. Die Container lasse ich bis Sicherheit herrscht die Restart policy auf never oder Unless stopped

Wird der Portainer am TWS von ElabNET geupdatet oder macht man das indem man das neue image im Portainer zieht?
Schöne Grüße
Gernot
_______________________________________________________
TWS 2600 ID:276 , VPN offen, Reboot nach Rücksprache erlaubt

StefanW
Elaborated Networks
Reactions:
Beiträge: 9689
Registriert: So Aug 12, 2018 9:27 am
Wohnort: Frauenneuharting
Hat sich bedankt: 4831 Mal
Danksagung erhalten: 7633 Mal
Kontaktdaten:

#19

Beitrag von StefanW »

murelli146 hat geschrieben: Di Mär 05, 2019 10:17 pmWird der Portainer am TWS von ElabNET geupdatet oder macht man das indem man das neue image im Portainer zieht?
Der Protainer wird - wie Grafana - von uns ausgeliefert und upgedated.

In den ersten Versionen war das anders, da hat sich der TWS beim booten immer das aktuellste Portainer Image gezogen, bis das schief gegangen ist, wel ein "saures" Update dabei war. Seither machen wir das eben nur noch kontrolliert und da wir - hust - gerade mit anderen Dingen stark beschäftiugt ist, werden wir nicht jedes kleine neue Release "durchrollen" können, weil wir wenigstens ein Minimum an Tests machen wollen.

Aber wenn Du Dich mit Portainer sehr gut auskennst, sind wir für Tipps, wenn sich was wichtiges dort tut, durchaus dankbar

lg

Stefan
Stefan Werner
Product Owner für Timberwolf Server, 1-Wire und BlitzART
Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Zu Preisen, Lizenzen, Garantie, HW-Defekt an service at elabnet dot de

Link zu Impressum und Datenschutzerklärung oben.

Ersteller
murelli146
Reactions:
Beiträge: 90
Registriert: Mi Jan 16, 2019 9:21 pm
Hat sich bedankt: 13 Mal
Danksagung erhalten: 50 Mal

#20

Beitrag von murelli146 »

StefanW hat geschrieben: Mi Mär 06, 2019 12:20 pm In den ersten Versionen war das anders, da hat sich der TWS beim booten immer das aktuellste Portainer Image gezogen, bis das schief gegangen ist, wel ein "saures" Update dabei war. Seither machen wir das eben nur noch kontrolliert und da wir
Danke für die Antwort, bin erst Docker Anfänger ;)

Meine Frage ziehlte eher darauf ab wenn ich images entwickle, update ich den Portainer am TWS oder downgrade ich mein Entwicklungssystem.
In diesem Fall downgrade ich damit ich die selben voraussetzungen wie am TWS habe.

Wollte gestern eine Anleitung verfassen da sind mir ein paar kleinigkeiten aufgefallen.
Aber das benötige ich eh nicht.

Im moment ist das für mir gelöst.

Vielen Dank für eure Geduld und Mühe!

Schöne Grüße
Gernot
Schöne Grüße
Gernot
_______________________________________________________
TWS 2600 ID:276 , VPN offen, Reboot nach Rücksprache erlaubt
Antworten

Zurück zu „Allgemeines“