root@server /srv/linbo # linbo-remote -i r219-pc09n -c create_cloop:1,upload_cloop:1
###
### linbo-remote (21720) start: Mo 28. Mär 13:00:01 CEST 2022
###
Sending command(s) to:
r219-pc09n ... Uploading secrets ... /usr/sbin/linbo-remote: Zeile 460: echo: Schreibfehler: Auf dem Gerät ist kein Speicherplatz mehr verfügbar.
/usr/sbin/linbo-remote: Zeile 463: echo: Schreibfehler: Auf dem Gerät ist kein Speicherplatz mehr verfügbar.
/usr/sbin/linbo-remote: Zeile 473: echo: Schreibfehler: Auf dem Gerät ist kein Speicherplatz mehr verfügbar.
/usr/sbin/linbo-remote: Zeile 467: echo: Schreibfehler: Auf dem Gerät ist kein Speicherplatz mehr verfügbar.
/usr/sbin/linbo-remote: Zeile 473: echo: Schreibfehler: Auf dem Gerät ist kein Speicherplatz mehr verfügbar.
/usr/sbin/linbo-remote: Zeile 477: echo: Schreibfehler: Auf dem Gerät ist kein Speicherplatz mehr verfügbar.
/usr/sbin/linbo-remote: Zeile 479: echo: Schreibfehler: Auf dem Gerät ist kein Speicherplatz mehr verfügbar.
/usr/sbin/linbo-remote: Zeile 480: echo: Schreibfehler: Auf dem Gerät ist kein Speicherplatz mehr verfügbar.
Started with PID unknown. Log see /var/log/linuxmuster/linbo/r219-pc09n.linbo-remote.
###
### linbo-remote (21720) end: Mo 28. Mär 13:00:01 CEST 2022
###
lag daran, dass ich /var auf dem Server hab voll laufen lassen…
das wiederum lag daran, dass irgendein rechner die linbo.log
das wiederum lag daran, dass irgendein rechner die linbo.log
rm r219-pc03n_linbo.log r219-pc04n_linbo.log |
auf Gigabyte Größe hat ansteigen lassen.
… was hat der Client den da so alles reingeschrieben?
… steht sowas auch „gehäuft“ in den logs der anderen?
Hast du eine Idee, warum „der“ das gemacht hat?
nein, ich habe in der Eile die beiden Dateien direkt gelöscht.
Kurz vorher reingeschaut habe ich viele Zeile von „no space left on device“ gesehen, was gut sein kann, weil das auch Rechner sind, mit denen ich ein neues Image probiert habe, was (v.a. wegen der geänderten devices sdX → nvmeX) eine neu-partitionierung nötig machte… (das „no space left on device“ kann schon irgendwie gewesen sein)
ob das allerdings die 1,5 GB an Dateigröße erklärt, weiß ich nicht. Hab nicht weiter geschaut, sorry. BAckup habe ich davon sicher auch keins.
jetzt hab ich es doch noch verfolgen können:
Ein Client, der ein neues IMage zieht, weril er in eine neue Klasse gekommen ist und dann ist die CAche-PArition voll, weil vorher das alte CLOOP nicht gelöscht wurde (kein AutoINitCAche)
Das wars auch schon. Wenn sich keiner erbarmt und den Rechner rebootet, ist das eine ENdlosschleife, die entweder sofort oder erst beim „reboot“ die /var Parition auf dem Server damit zumüllt.
Hi Alois,
das ist die falsche Richtung, bei Tobias gehts darum, dass der Client ein Image geholt hat. Hatte ich auch schon, dass das dann nicht auf die Cache-Partition passt. Ggf. wäre es sinnvoll, dort immer alle nicht benötigten cloops zu löschen (wann braucht man die alten schonmal wieder…)
LG
Max
Es ist keine Endlosschleife, ich muss mich festhalten: Die Rechner a.k.a der Bus inkl. NVMe ist so schnell, dass der Rechner so viele Zeilen „[StdErr] error, write failed at 5265555456 on file „jammymate-lc7.cloop“: No space left on device“ raushaut, bis der bittorrent timeout kommt.
aber dann sind halt schon ~500MB voll… z.B.
dann macht der Client rsync, was natürlich auch schief geht.
so sieht es jedenfalls aus.
(ist alles noch innerhalb von linbo2, habe noch nichts in Richtung linbo4 unternommen)
LG, Tobias
P.s. jetzt hinlegen nach durchzechter Nacht, Kratzen im Hals kommt wieder, kann ich mir wieder einen Test heute sparen…
Es sollte auf jeden Fall dokumentiert werden, dass man per initcache den Clientcache aufräumen sollte, wenn man den Imagenamen ändert. Linbo >= 4.0.17 bricht den Download ab, wenn im Cache kein Platz mehr ist. Ich sehe da jetzt im Moment keine Notwendigkeit an dem Verhalten was zu ändern.
ich habs vorhin mal getestet. Ein „initcache“ löschte die Images, die nicht mehr in der start.conf standen, danach wurden die Images downgeloadet welche in der start.conf standen.
ja, das hat auch bei mir schon immer funktioniert.
Nur, wenn man kein AutoINitCache= true/yes in der start.conf stehen hat und initcache:… nicht explizit angibt, also dementsprechend kein initcache stattfindet, dann werden auch keine images gelöscht.
Ich habe das (autoinitcache) standardmäßig auch bei mir aktiviert, aber ich falle immer (in den letzten Jahren) wieder bei Tests auf die Nase, weil die CAchepartition voll lief. In diesem Fall lief dann in der Folge auf dem Server /var voll … was natürlich ein unangenehmer aber hoffentlich seltener NEbeneffekt ist.
VG, Tobias
„Narrensicher“ ist halt relativ. Hängt von der Zielsetzung ab. Mensch muss, wie bei allen anderen Dingen auch, wissen was mensch tut.
initcache ist gut, wenn
wenn ein neues Image nur in den Cache heruntergeladen werden soll,
der Client mehrere Images für mehrere BS vorhält und neue Versionen in einem Schwung in den lokalen Cache heruntergeladen werden sollen,
wenn es für den Client ein Image mit neuem Namen gibt und sichergestellt werden soll, dass vor dem Herunterladen das Image mit dem alten Namen gelöscht wird um Platzproblemen im Cache vorzubeugen.
initcache ist überflüssig, wenn nur ein BS mit einem neuen Image gesynct werden soll und es keinen Grund gibt den Cache aufzuräumen. Das Image wird auch mit sync heruntergeladen.
initcache ist schlecht, wenn der Client mehrere Images vorhält und beim Sync dann u.U. länger als nötig unbenutzbar ist, weil zuerst alle neuen Images (nicht nur das zu syncende) heruntergeladen werden.
autoinitcache führt initcache bei jedem Linbo-Start aus. Aufgabe: Wann ist das sinnvoll?
Cache beinhaltet ein altes, aber nicht mehr gewolltes Image
Cache beinhaltet zwei alte, aber gewollte Images
Cache beinhaltet zwei aktuelle Images
Cache beinhaltet zwei alte, aber nicht mehr gewollte Images
Fall 1, das Image wird geladen ohne „initcache“
Fall 2, das neue Image wird geladen ohne „initcache“, das alte wird gelöscht
Fall 3, nichts passiert, ob mit oder ohne „initcache“
Fall 4, ohne „initcache“ läuft man Gefahr, dass der Cache voll läuft, mit „initcache“ wird das überflüssige Image gelöscht
Fall 5, die Images werden geladen ohne „initcache“, die alten Images werden gelöscht
Fall 6, nichts passiert, ob mit oder ohne „initcache“
Fall 7, ohne „initcache“ läuft man Gefahr, dass der Cache voll läuft, mit „initcache“ werden die Images gelöscht und die neuen Images geladen
Warum sollte man nicht „autoinitcache“ einschalten? Soweit ich das sehe, werden aktuelle Images nicht angefasst, wenn sie schon im Cache sind.
Viele Grüße
Alois
Ps. Die Liste erhebt keinen Anspruch auf Vollständigkeit
