[Problem] Werkseinstellung bei rescue

[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?

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

[ms20de]

Wie kann ich den "Verbrauch der Filedeskriptoren" untersuchen bzw. Sichtbar machen?

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?

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

[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

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

Viele Grüße,
Matthias

[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?

Akustikkoppler-Geschwindigkeit

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

Schöne Grüße
Gernot

[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

[StefanW]

Hallo Gernot,

Falls 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

[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?

[StefanW]

Wird 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

[murelli146]

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