/var voll - linbo_remote funktioniert nicht mehr

Clientpflege linbo
#1 
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

rm r219-pc03n_linbo.log r219-pc04n_linbo.log

auf Gigabyte Größe hat ansteigen lassen.

Vielleicht hilft es jemand,
Tobias

#2

Hallo Tobias,

Danke für den Hinweis.

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?

LG

Holger

#3

Hallo Holger,

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.

VG, Tobias

#4

Hi Holger,

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.

VG, Tobias

#5

@thomas

Hallo Thomas,

ließe sich diese Fehlerquelle irgendwie abfangen?

Beste Grüße

Thorsten

#6

Hallo Thorsten,

Siehe: Keine Fehlermeldung beim Erstellen von Images bei zu kleinem Cache - #18 von MachtDochNix

Viele Grüße

Alois

#7

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

#8

Hallo Alois,

passt nicht, da der Fehler ja den Server zu müllt. Was ja viel schlimmer ist.

Beste Grüße

Thorsten

#9

Hallo Max,

dann könnte man doch dem linbo-remote-Befehl ein „partition“ mitgeben, dann ist das Problem gelöst.

Gruß

Alois

#10

Hallo!

Bei Tobi war es ja ein Client, der in eine neue Hardwareklasse geschoben wurde. Für den Fall gibt es zwei Lösungsansätze:

Irgendwie abfangen (Daher meine Anfrage an @thomas)
oder
das muss mit einem Ausrufezeichen in die Doku!

Ersteres wäre die beste Lösung, denn wer liest schon die Doku. :wink:

Beste Grüße

#11

Hallo,

ich habe ein Feature Request eingestellt.

LG

Holger

#12

Hi zusammen,
ich korrigiere mich geringfügig:

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…

#13

Hallo Tobias,

Gute Besserung.

Viele Grüße Alois

#14

Hi!

Gute Besserung an @Tobias.

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.

VG, Thomas

#15

Moin!

Issue ist angelegt: #727

Beste Grüße

Thorsten

2 „Gefällt mir“
#16

Hallo Tobias,

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.

Viele Grüße

Alois

#17

Hallo Alois,

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

#18

Hallo,

stellt sich mir die Frage wie wir das Narrensicher in der Doku beschreiben sollten:

Erstellung eines (neuen) Images

  1. Sync-Start des Clients mit initcache
  2. …

Beste Grüße

Thorsten

#19

Moinsen!

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

VG, Thomas

#20

Hallo,

welche Szenarien gibt es?

  1. Cache ist leer
  2. Cache beinhaltet ein altes, aber gewolltes Image
  3. Cache beinhaltet ein aktuelles Image
  4. Cache beinhaltet ein altes, aber nicht mehr gewolltes Image
  5. Cache beinhaltet zwei alte, aber gewollte Images
  6. Cache beinhaltet zwei aktuelle Images
  7. 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