[GELÖST] Proxmox LXC-Container - Python3.6 Installation überflutet RAM

[CapaU]

Hallo liebe Community,

Ich habe schon seit einiger Zeit mir einen eigenen Root-Server zugelegt und auf diesen Debian(Proxmox) aufgesetzt. Habe einige VM's laufen und läuft auch alles super. Nun hatte ich mich mal mit den LXC-Containern auseinandergesetzt und damit ein wenig rumgespielt, um erstmal in Erfahrung zu bringen, was so ein Container denn eigentlich ist. Ich bin von diesem System ziemlich begeistert und habe dementsprechend auch, seit ich nun weiß, was das ist, einen Container mit einem dementsprechenden Serverdienst am laufen.

Nun wollte ich ein weiteren Container erstellen, wo ich noch andere Dienste, die ich derzeit auf einer VM laufen habe, innerhalb des Containers aufsetzen wollte. Gesagt getan, ich habe einen weiteren Container erstellt und wollte den ersten Server installieren. Hierbei handelt es sich um den Red-Discord Bot. Ich habe diesen auch bereits in meiner VM laufen, läuft alles super. Nun will ich diesen ja in meinen Container aufsetzen und ich brauche für diesen Server Python3.6, also muss ich zuerst Python installieren, damit ich mein RedBot danach aufsetzen kann. Auch hier wieder gesagt getan, ich wollte nun Python installieren, habe mir dazu diese Anleitung hier genommen: https://twentysix26.github.io/Red-Docs/ ... ll_debian/

Nun hatte ich Python, so wie in der Anleitung beschrieben installiert (So wie ich es ja sonst auch immer gemacht habe, auf meiner VM + meinen Pi usw). Plötzlich nichts ahnend hatte ich aufeinmal die Verbindung zu meiner Server verloren und dieser war nicht mehr erreichbar. Ich habe mich natürlich gewundert und überlegt, was los sei, also habe ich mich mit einer KVM-Konsole draufgeschaltet und gesehen, das mein Server total am durchdrehen war. Hier hat nur noch ein Hardreset geholfen..
Ich habe daraufhin mich natürlich total gewundert und mir gingen die seltsamsten Gedanken durch den Kopf, weshalb dies jetzt passiert ist. In der Rsyslog habe ich dann gesehen, dass da irgendwas mit out-of-memory stand und sich dieses OM-Killer Dings da eingeschaltet hat, was mich verwunderte, weil ich gerade mal ungefähr mit allen Diensten, die aktuell auf meinen System laufen, so um die 8-10 GB RAM von 32 GB RAM verbrauche - Ich habe dem Container im übrigen nur 2GB RAM zugewiesen.

Ich beschloss am nächsten Tag, das ganze erneut zu versuchen, diesmal hatte ich aber alles mögliche zum Debuggen und überwachen an. Heißt: hatte htop an auf meinen Host-System sowie die ganze Zeit auf meiner Syslog geschaut, was denn jetzt genau passiert, habe erneut die Python-Installation innerhalb des Containers begonnen und die ganze Geschichte beobachtet. Dann irgendwann, als er bei dem Punkt "Test_Socket" stand, schoss mit einmal der RAM des Host-Systems in die Höhe und hat diesen quasi richtig "aufgeladen", ich habe den ganzen Prozess natürlich abgebrochen, um einen weiteren Systemabsturz zu vermeiden. Ja, nun bin ich an den Punkt, an dem ich nicht weiter komme und auch bei meinem eigentlichen Hilferuf, wenn man so will

Also nochmal zusammengefasst:
1.

• Ich habe einen LXC-Container(Proxmox) erstellt, mit dem Debian-Template, dass man sich bei Proxmox herunterladen kann, dieses habe ich installiert und gestartet.

2.

• Innerhalb dieses Containers soll der Redbot installiert werden, der aber, um zu laufen, die Software Python braucht, speziell die 3.6er Version.

3.

• Bei der Python-Installation, wenn ich den Befehl "make -j4" (Siehe verlinkte Anleitung) ausführe, kommt er dann irgendwann an den Punkt, bei dem "Test_Socket" steht, danach geht es offensichtlich nicht mehr weiter und ich kann bei Htop am Host-System beobachten, wie der RAM in die Höhe schießt, sollte ich diesen Prozess von Python nicht beenden, führt dies zum Absturz des Host-Systems bzw. zum totalen Zusammenbruch der Prozesse meines Servers, da der RAM überladen wird.

Zudem hat mir die Syslog vom Host-System auch noch irgendwas ausgegeben, als Python innerhalb des Containers am Punkt "Test_Socket" war:

Code: Alles auswählen

Apr 06 10:13:18 Juray-Master kernel: can: controller area network core (rev 20170425 abi 9)
Apr 06 10:13:18 Juray-Master kernel: NET: Registered protocol family 29
Apr 06 10:13:18 Juray-Master kernel: can: raw protocol (rev 20170425)
Apr 06 10:13:18 Juray-Master kernel: NET: Registered protocol family 21
Apr 06 10:13:18 Juray-Master kernel: NET: Registered protocol family 38
Apr 06 10:13:18 Juray-Master kernel: sctp: Hash tables configured (bind 512/512)
Apr 06 10:13:41 Juray-Master kernel: can: broadcast manager protocol (rev 20170425 t)

Man muss dazu sagen, dass sie dies nur einmal getan hat, sprich, als ich das Host-System neugestartet habe, nur nach einem Neustart des Host-Systems zeigt die Rsyslog das an, während innerhalb des Containers Python installiert wird, führe ich das dann wieder aus, also die Python-Installation "make -j4", zeigt die Rsyslog vom Host-System dies nicht nochmal an, nur (so anscheinend) wenn ich das Host-System neugestartet habe und die Python Installation dann erneut im Container ausführe.

Ich habe zudem, wegen dem Punkt mit dem RAM-Überfluten, auch noch ein kurzes Video gemacht, wo man die ganze Geschichte mal in Aktion sieht, natürlich habe ich rechtzeitig abgebrochen, weswegen habe ich ja bereits beschrieben, hier das Video: https://www.youtube.com/watch?v=zejvZqpCmio

Ja, nun hoffe ich, dass einer von euch mir da helfen kann und vielleicht eine Ahnung hat, warum dies passiert und auch, was ich dagegen tun kann.

Danke im voraus

[cronoik]

Eine richtige Antwort kann ich dir leider nicht geben, aber vielleicht kannst du Python-3.6.0/Lib/test/test_socket.py etwas kuerzen (in der Methode test_main ein paar Tests entfernen). Am besten erzeugst du mal einen Bugreport [1].

[1] https://bugs.python.org/

[CapaU]

Eine richtige Antwort kann ich dir leider nicht geben, aber vielleicht kannst du Python-3.6.0/Lib/test/test_socket.py etwas kuerzen (in der Methode test_main ein paar Tests entfernen). Am besten erzeugst du mal einen Bugreport [1].

[1] https://bugs.python.org/

Okay, danke.

Dann werde ich mal gucken, was sich machen lässt.

[CapaU]

Habe das Problem gelöst, indem ich die "Test_Socket.py" rausgeworfen habe, hat dann alles geklappt, auch das Setup vom Bot lief. Danke dafür

Falls es irgendwelche Nachteile oder Probleme geben sollte, werde ich hier natürlich darüber berichten.

[hikaru]

Ich kenne die Details des Python-Builds nicht, aber ein make kann je nach Code gern mal zweistellige GB an RAM verbrauchen. Ich hätte fast darauf gewettet, dass das in einem Container mit 2GB gegen die Wand geht. Wenn der Container auch keinen Zugriff auf ausreichend Swap hat, muss halt der OOM-Killer zuschlagen. Warum der dann durchdreht und den Host mitreißt ist eine andere Frage und sollte geklärt werden.

Mit anderen Worten: Hättest du dem Container für den Pyton-Build deutlich mehr RAM gegönnt, hätte es vermutlich funktioniert. Für den eigentlichen Betrieb hättest du ihn dann wieder einschränken können.
Das führt in zweiter Überlegung dazu, Build- und Produktivsystem zu trennen. Du hast nun in deinem Container eine Menge Ballast, den du ausschließlich für den Python-Build brauchtest, der im Produktivbetrieb aber nur unnütz rumliegt.
In dritter Überlegung vermute ich, dass die Anleitung aufgrund ihres Alters unnötig kompliziert ist. Zumindest dürfte sie unötig "dreckig" sein, da sie auf checkinstall verzichtet. In Buster liegt python3 in Version 3.7 vor, was hoffentlich die 3.6-Abhängigkeit erfüllen kann. Die sauberste und hoffenlich auch einfachste Methode wäre mMn ein Backport von python 3.7.

[CapaU]

Ich kenne die Details des Python-Builds nicht, aber ein make kann je nach Code gern mal zweistellige GB an RAM verbrauchen. Ich hätte fast darauf gewettet, dass das in einem Container mit 2GB gegen die Wand geht. Wenn der Container auch keinen Zugriff auf ausreichend Swap hat, muss halt der OOM-Killer zuschlagen. Warum der dann durchdreht und den Host mitreißt ist eine andere Frage und sollte geklärt werden.

Mit anderen Worten: Hättest du dem Container für den Pyton-Build deutlich mehr RAM gegönnt, hätte es vermutlich funktioniert. Für den eigentlichen Betrieb hättest du ihn dann wieder einschränken können.
Das führt in zweiter Überlegung dazu, Build- und Produktivsystem zu trennen. Du hast nun in deinem Container eine Menge Ballast, den du ausschließlich für den Python-Build brauchtest, der im Produktivbetrieb aber nur unnütz rumliegt.
In dritter Überlegung vermute ich, dass die Anleitung aufgrund ihres Alters unnötig kompliziert ist. Zumindest dürfte sie unötig "dreckig" sein, da sie auf checkinstall verzichtet. In Buster liegt python3 in Version 3.7 vor, was hoffentlich die 3.6-Abhängigkeit erfüllen kann. Die sauberste und hoffenlich auch einfachste Methode wäre mMn ein Backport von python 3.7.

Hi,

Ich habe auch den RAM innerhalb des Containers beobachtet (Htop), der stieg dort nicht an und hatte keine große Auslastung gehabt, SWAP steht ihm zur Verfügung.
Zudem hatte ich meiner vorherigen VM, wo es auch problemlos geklappt hat, auch nur 2 GB RAM zugewiesen und da lief alles

Vielleicht liegt ja da tatsächlich irgendwas in der Mitte von beiden Möglichkeiten, ich bin jedenfalls froh, dass es nun funktioniert ^^

Meine Vermutung die ich ja hatte, wäre die, dass er bei dem "Test_Socket" irgendwas ausführt, was mit an's Host-System durchgeliefert wird, er dann irgendwas innerhalb des Containers nicht richtig gebacken bekommt und in einer Art Endlosschleife festhängt und dadurch immer wieder die selben Befehle ausführt, die irgendwie an's Host-System gehen und das immer wieder macht und sich dadurch der RAM vom Host-System auffüllt (Weil die Signale an dieses gehen), weil er sich auch selber nicht beendet, bzw. selber nicht zum Abschluss des Skripts kommt.