Ubuntu LXC einfach aus
- Ersteller UnBreakable
- Erstellt am
- Registriert
- Sep. 2005
- Beiträge
- 456
Also die ersten Tests damit waren erfolgreich. Ich werde es mal weiter beobachten.
Ist weniger Aufwand und Ressourcen schonender als auf eine VM umzusteigen.
Ich habe mich kurz eingelesen, aber auf die schnelle weiß ich nicht, ob meine Anforderung relativ leicht erfüllbar wäre.
Und sollte mein Script jetzt dauerhaft funktionieren, habe ich ehrlichgesagt keine Lust mehr mich noch ewig damit zu beschäftigen)
Mein Ziel ist es ja, nur die jüngste .VBK Datei zu kopieren und alle jüngeren .VIB Dateien dazu. Alles andere zu löschen. Unabhängig davon immer die .vbm Datei und nicht löschen.
- Registriert
- Sep. 2005
- Beiträge
- 456
Also was ich genau wollte, habe ich einen Beitrag über dir geschrieben.
Es geht bestimmt irgendwie. Aber mir war auf den ersten Blick nicht ersichtlich wie.
Naja ich dachte mir, dann schreibe ich eben schnell ein kleines Python Script.
Ich dachte nicht, dass daraus so ein Drama wird ;-)
Das hier ist ja nicht mein einziges Problem.
Es ist echt unglaublich wie schwierig ein einfaches "ein par Dateien wegkopieren" werden kann.
Ergänzung ()
Ok, ich habe mich zu früh gefreut, ich hab die Lösung immer noch nicht, nach mehreren Tests ist der Container wieder abgestürzt.
Ich versuche es nun mit einer VM anstatt eines Containers. Das ist leider etwas mehr Aufwand und wird etwas dauern.
Zuletzt bearbeitet:
oicfar
Captain
- Registriert
- Juni 2020
- Beiträge
- 3.569
Was macht dein Skript. Kopiert Dateien von Links nach Rechts und wennUnBreakable schrieb:
Code:
if(os.path.getsize(dest+element) == os.path.getsize(source+element)):Ich kopiere regelmäßig ca. 500GB an Dateien. Und das mache ich mit rsync. Es ist eine Sicherheitskopie. D.h. ich lösche das Original nicht.
Dein Skript ist ein guter Anfang. Bedarf jedoch einiger Verbesserungen.
Ergänzung ()
VM Aufsetzen und das was du brauchst einzurichten, sollte schon fix gehen.UnBreakable schrieb:
Zuletzt bearbeitet:
- Registriert
- Sep. 2005
- Beiträge
- 456
Dass das nicht perfekt ist, ist mir durchaus bewusst.
Ja ich weiß. Mir ging es hier eher darum, falls der Kopiervorgang abgebrochen wurde.
So Dinge wie Hashwerte kontrollieren habe ich schon auf dem Schirm. Aber erstmal will ich das Script überhaupt zum laufen bringen.
Und löscht. Aber beim Ziel, nicht bei der Quelle. Außerdem werden nur bestimmte Dateien kopiert, nicht alle.
Genau darum geht es mir doch.
Ergänzung ()
Ganz so einfach ist es nicht. Es geht auch noch im Firewall Settings, sowohl lokal, als auch am Router usw.
Es läuft jetzt allerdings schon, habe die einfacherer Variante genommen und die IP-Adresse des Containers übernommen.
riversource
Captain
- Registriert
- Juli 2012
- Beiträge
- 3.268
Du kannst einfach einen rsync Aufruf starten und über die Kommandozeile bestimmen, dass nur ältere Dateien überschrieben werden. Dann wird nur kopiert, wenn es in der Quelle ein Update gibt. Ist eine Zeile, ein einziger Aufruf. Dafür braucht es nicht mal einen Container, das kann man auch direkt auf dem Host machen.
- Registriert
- Sep. 2005
- Beiträge
- 456
Das ist aber nicht das was ich brauche.
In der Quelle befinden sich mehrere VBK und auch mehrere VIB Dateien die auch älter sind.
Aber eben nur die Jüngste VBK Datei (eine!) und alle VIB Dateien die jünger als diese VBK Datei sind. Alle anderen Dateien werden nicht kopiert und falls im Ziel vorhanden gelöscht.
Und das Script kann weder auf der Quelle noch auf dem Ziel laufen.
In der Quelle befinden sich mehrere VBK und auch mehrere VIB Dateien die auch älter sind.
Aber eben nur die Jüngste VBK Datei (eine!) und alle VIB Dateien die jünger als diese VBK Datei sind. Alle anderen Dateien werden nicht kopiert und falls im Ziel vorhanden gelöscht.
Und das Script kann weder auf der Quelle noch auf dem Ziel laufen.
riversource
Captain
- Registriert
- Juli 2012
- Beiträge
- 3.268
Auch das geht mit rsync, da kann man Timestamps gewisser Dateien als Basis für Kopier- oder Löschvorgänge heranziehen.
dms
Commander
- Registriert
- Dez. 2020
- Beiträge
- 2.700
Mit Verlaub, dein Skript zum lernen und wegwerfen mag das OK sein, die Architektur mehr als NAJA - erscheint überkomplex und von dir mit Verlaub unbeherscht .. jetzt also via VM
..und dem "SW-DING" willst du ein Backup anvertrauen?
Aber RSYNC was genau zu diesem Zweck unter Unixoiden sehr Jahren diese Dinge leistet ist dir zu komplex?
Was ist denn das Ziel:
A) ein funktionierendes Backup
B) lernen und verstehen wie man Software Implementiert?
..und dem "SW-DING" willst du ein Backup anvertrauen?
Aber RSYNC was genau zu diesem Zweck unter Unixoiden sehr Jahren diese Dinge leistet ist dir zu komplex?
Was ist denn das Ziel:
A) ein funktionierendes Backup
B) lernen und verstehen wie man Software Implementiert?
Naja, man kann sowas schon auch mit einem eigenen Skript machen, wenn die Anforderung mit einem Tool evtl. nicht 100% umsetzbar ist. Ich wüsste jetzt auch nicht aus dem Stegreif, wie ich die Anforderung des TE mit rsync umsetzen würde, habe das bisher aber auch immer nur "straight-forward", sprich Quelle und Ziel synchron halten, benutzt.dms schrieb:
Aber darum (und ob es alternative Ansätze gibt, z.B. die scheinbar unnötigen Dateien einfach vorab an der Quelle zu löschen) soll es hier gar nicht gehen.
Die Ausgangssituation war ja, dass der LXC Container einfach abgeschossen wird, wir haben nun rausgefunden, dass das sowohl mit shutily.copy2 als auch mit einem cp Kommando passiert. Vermutlich liegt es also nicht am Skript des TE, sondern daran, dass der Kopieren von einem SMB Share auf ein anderes SMB Share aus dem LXC Container heraus nicht stabil funktioniert.
Es ist zu befürchten, dass es eventuell auch mit rsync das gleiche Problem auftritt. Kann auch sein, dass es nicht der Fall ist, weil rsync eigene Kopierroutinen verwendet, denn rsync kann ja auch Dateien die nur partielle Änderungen aufweisen, partiell kopieren.
Also auch die Umstellung auf rsync wäre nicht wirklich Ursachenbekämpfung.
Bisher ist nur da Symptom bekannt: Der Container (bzw. Prozess) wird wegen einer Überschreitung der cgroup Speicherquote abgebrochen.
Was man beim letzten vom TE erstellten Dump sieht, ist dass am Ende der Abbruch beim Senden eines tcp segments abbricht, nachdem im Folge von sendfile allerlei Code vom Filesystem und vom cifs (Samba) Client durchlaufen wurde.
Damit stellt sich natürlich automatisch die Frage, ob das Problem auch bei lokalen Filesystemen auftreten würde, usw. Leider also viele potenzielle Möglichkeiten die man eingrenzen müsste.
oicfar schrieb:
Die dritte wäre das Problem mit der cgroup Quota zu lösen. Ich kann da selber leider nichts zu beitragen, ich habe LXC noch nie benutzt. Ich habe mich hier nur eingebracht, da sich anscheinend noch niemand die Mühe gemacht hatte, die Stackdumps zu analysieren.
riversource
Captain
- Registriert
- Juli 2012
- Beiträge
- 3.268
Ich vermute das Problem eher bei Python. SMB Zugriffe aus einem Container sind eigentlich kein Problem.TomH22 schrieb:
Und wieso bricht er bei einem cp Komanndo da auch ab?riversource schrieb:
Hast Du meine Ausführungen zu dem Stackdump weiter oben eigentlich gelesen?
Also noch mal zur Zusammenfassung:
Der ursprüngliche Code des TE ruft shutil.copy2 in Python auf. Diese Python Routine nutzt laut Doku den sendfile syscall um die Datei zu kopieren, Python ist also für den eigentlichen Kopiervorgang gar nicht mehr im Spiel.
"Downstream" im Stack zu Sendfile gibt es dann irgendwann einen Abbruch, weil der Prozess das cgroup Speicherlimit überschreitet. Das passiert beim Senden einen tcp Segments an den smb Server. Das senden dieses Segments direkt wird aber nicht das Problem sein, es ist vermutlich einfach nur der Aufruf, bei dem das Speicherlimit überschritten wird (sozusagen das eine Minzplätzchen zu viel...)
Interessant sind auch die cgroup Stats in dem Dump:
Code:
2024-02-13T14:43:39.434807+01:00 pve kernel: [12371970.567640] Memory cgroup stats for /lxc/108:
2024-02-13T14:43:39.434808+01:00 pve kernel: [12371970.567684] anon 0
2024-02-13T14:43:39.434809+01:00 pve kernel: [12371970.567684] file 256684032
2024-02-13T14:43:39.434810+01:00 pve kernel: [12371970.567684] kernel 11747328
2024-02-13T14:43:39.434811+01:00 pve kernel: [12371970.567684] kernel_stack 425984
2024-02-13T14:43:39.434812+01:00 pve kernel: [12371970.567684] pagetables 1261568
2024-02-13T14:43:39.434813+01:00 pve kernel: [12371970.567684] sec_pagetables 0
2024-02-13T14:43:39.434814+01:00 pve kernel: [12371970.567684] percpu 700440
2024-02-13T14:43:39.434815+01:00 pve kernel: [12371970.567684] sock 4096
2024-02-13T14:43:39.434815+01:00 pve kernel: [12371970.567684] vmalloc 487424
2024-02-13T14:43:39.434816+01:00 pve kernel: [12371970.567684] shmem 0
2024-02-13T14:43:39.434817+01:00 pve kernel: [12371970.567684] zswap 0
2024-02-13T14:43:39.434818+01:00 pve kernel: [12371970.567684] zswapped 0
2024-02-13T14:43:39.434819+01:00 pve kernel: [12371970.567684] file_mapped 0
2024-02-13T14:43:39.434820+01:00 pve kernel: [12371970.567684] file_dirty 655360
2024-02-13T14:43:39.434821+01:00 pve kernel: [12371970.567684] file_writeback 255520768
2024-02-13T14:43:39.434821+01:00 pve kernel: [12371970.567684] swapcached 0Unter file und file_writeback stehen recht hohe Werte. Das ist vermutlich die Menge an Speicher die für den file Cache des Kernels in der cgroup verbraucht wird. Sicher bin ich mir da nicht, ich habe da eben mal ein wenig gesucht, aber das ganze cgroup Feature ist schon recht komplex, da steigt man nicht mal in ein paar Minuten durch.
Aber ich fürchte, wenn man das Problem lösen will, muss man sich damit beschäftigen.
oicfar
Captain
- Registriert
- Juni 2020
- Beiträge
- 3.569
Für alles gibt's eine Lösung.
https://grafana.com/grafana/dashboards/10048-proxmox/
Man muss den Host und die Guests im Auge behalten.
- Aktueller Ansatz sollte stabil laufen.
- Verbesserungen am Skript, falls gewünscht.
Monitoring mit Influx/Grafana kann man easy einrichten.riversource schrieb:
https://grafana.com/grafana/dashboards/10048-proxmox/
Man muss den Host und die Guests im Auge behalten.
oicfar
Captain
- Registriert
- Juni 2020
- Beiträge
- 3.569
Ist das https://www.techtarget.com/whatis/definition/write-back hier gemeint?TomH22 schrieb:
Ergänzung ()
Monitoring ist bei solchen Problemen hilfreich um zu sehen wie sich das System verhält. Und wenn man schon so was im Einsatz hat, dann setze ich ein bestehendes Monitoring eh voraus.TomH22 schrieb:
Ergänzung ()
Optional kann man atop nehmen und jede Sekunde die Werte aufzeichnen und dann kann man alles abspielen um zu sehen, wie sich das System verhält. Für so was ist atop super.
Zuletzt bearbeitet:
riversource
Captain
- Registriert
- Juli 2012
- Beiträge
- 3.268
Weils auch aus einem Python Script aufgerufen wird. Er hat ja nur den shutil Aufruf verändert.TomH22 schrieb:
Doch, nach wie vor werden die Aufrufe aus einem Python Script getätigt. Python und sein Memory Management ist also noch nicht raus.TomH22 schrieb:
Bislang wissen wir ja auch nur, dass der Container während des Kopiervorgangs crasht, aber nicht, dass auch wirklich der Kopiervorgang oder das Copy Commando dafür verantwortlich ist. Im Moment kommen sogar noch Betriebssystem-Funktionen infrage.
Es kann auch ein Problem im Zusammenhang mit SMB sein. Von der Quelle kann schneller gelesen werden, als auf das Ziel geschrieben werden kann, und irgendein Zwischenspeicher läuft voll.
- Registriert
- Sep. 2005
- Beiträge
- 456
Nein
Ich finde keine Option von rsync die meinen Zweck erfüllt.
Ich könnte natürlich über ein Script, für jede Datei anstatt den copy Befehl rsync ausführen. Aber was ist dann viel besser?
Keine Ahnung wie du das beurteilen willst, aber das ist ja auch nicht das Thema.
Eine große Datei zu kopieren
Ist es doch bereits.
Das stimmt. Aktuell vermute ich einen Hardwaredefekt der Festplatte.
Nachdem ich nach einem Update den Proxmox-Host neu starten wollte kam der erstmal nicht mehr hoch.
Auf der Festplatte wurde keine Bootpartition mehr gefunden. Daraufhin habe ich Proxmox neu installiert.
Komischerweise wurde auch auf den zwei zusätzlichen Festplatten nichts mehr gefunden. (Weiß ich aber nicht, wie das bei einer frischen installation normalerweise ist)
Habe darauf hin Proxmox neu installiert.
Wollte dann das erste Backup einspielen, was schon lange gedauert hat. Hab es dann abgebrochen.
Daraufhin wurde in Proxmox nur ein ? bei den Festplatten angezeigt. Habe dann nochmal einen Neustart versucht und das gleiche Problem wieder: Keine Bootpartition gefunden.
Ich werde jetzt wohl erstmal eine andere Festplatte als Bootpartition testen und dann berichten.
(Zieht sich alles etwas, da das Gerät auch nicht bei mir vor Ort steht)
Aber ich könnte mir gut vorstellen, dass die Kopierprobleme auch damit zusammenhängen.
