pkg upgrade geht schief: Child process pid=xxxxx terminated abnormally: Killed

i18n

Well-Known Member
Heute kam ein dickes Upgrade der Packete (418) wegen python-37 -> python-38. Mein Rechenknecht ist altersschwach, hat weder viel Festplattenspeicher (19 G - davon 6 frei) noch viel RAM (512 M). Filesystem ist ZFS. Habe in den Foren gelesen, daß dieser Fehler auftaucht, wenn zu wenig Arbeitsspeicher+Swap vorhanden ist, daß aber durch die Erhöhung der Swap-Partition die Installation der Pakete dann durchläuft.
Soweit ich das verstanden habe, ist doch die Swap-Partition bei ZFS dynamisch, oder? Sie müßte sich damit automatisch vergrößern.

Meine Frage jetzt: kann ich
a) das Upgrade der Pakete in Schüben durchführen lassen, also, daß er nicht alles auf einmal installiert und somit der virtuelle Swap volläuft?
b) irgendwie den Swap unter ZFS vergrößern, so daß diese Menge an Paketen dennoch installiert wird?
c) gibt es eine dritte Lösung, die mir noch nicht eingefallen ist?

Wäre für jede Hilfe sehr dankbar, will nicht den ganzen Rechner wieder neu aufsetzen, jetzt, wo er gerade so schön rund läuft.
 
Welche FreeBSD Version verwendest du? Ich sehe da am ehsten das Problem das der ARC von ZFS vollläuft und nicht rechtzeitig freigeben kann. 512MB Ram mit ZFS ist .. suboptimal :D. Ab 13.0 sollte das besser laufen, aber ich weiß nicht wie besser bei so wenig RAM.

Eventuell probieren den ARC zu begrenzen - auf 256 MB oder so, aber kA ob dann ZFS noch läuft, selbst bin ich nie unter 1GB ARC Cache gegangen.

Zum Thema Swap: Nein der Swap wird nicht dynamisch größer, es sollte aber mit ZFS sehr einfach sein dein Swap zu vergrößern. Um mehr zu sagen müsstest du aber etwas über das ZFS Layout preisgeben :)

Du kannst natürlich versuchen die Pakete einzeln zu updaten, pkg update <paket>. Aber auch da gibts Abhängigkeiten die gemeinsam upgedated werden müssen, und gerade bei python upgrade sollte das ne Menge sein - hier hilft nur ausprobieren.
 
FreeBSD 13.0 p3, bei der Installation habe ich FreeBSD automatisch die ZFS-Partitionen anlegen lassen.
df -H sagt mir:
Filesystem Size Used Avail Capacity Mounted on
zroot/ROOT/default 19G 13G 6,0G 69% /
devfs 1,0k 1,0k 0B 100% /dev
procfs 4,1k 4,1k 0B 100% /proc
fdescfs 1,0k 1,0k 0B 100% /dev/fd
zroot/var/mail 6,0G 123k 6,0G 0% /var/mail
zroot/tmp 6,0G 139k 6,0G 0% /tmp
zroot/var/log 6,0G 541k 6,0G 0% /var/log
zroot/usr/ports 8,2G 2,2G 6,0G 27% /usr/ports
zroot/usr/home 14G 7,6G 6,0G 56% /usr/home
zroot 6,0G 98k 6,0G 0% /zroot
zroot/var/audit 6,0G 98k 6,0G 0% /var/audit
zroot/var/tmp 6,0G 98k 6,0G 0% /var/tmp
zroot/usr/src 6,7G 736M 6,0G 11% /usr/src
zroot/var/crash 6,0G 98k 6,0G 0% /var/crash
 
Ach ja, sowohl der Pool als auch das Swap sind verschlüsselt. Swap ist der Standard, also 2 GB. Bislang lief alles ohne Probleme, auch bei größeren Upgrades stellte sich FreeBSD nicht quer.
 
Mach mal ein zfs list bitte.

Aber probier mal den ARC zu limitieren, in der loader.conf vfs.zfs.arc_max="128M" (z.b.). Wie ZFS darauf reagiert kann ich dir aber nicht sagen. Dann natürlich ein Reboot.

Ansonsten ist interessant was dmesg sagt, nachdem er dein pkg abgeschossen hat.
 
Danke für Dein Bemühen, mir zu helfen. Hier die beiden Ausgaben von zfs list und dmesg.

Wie ich dmesg entnehme, ist es wirklich der fehlende Swapspace, der mir den Prozeß abwürgt.
 

Anhänge

  • zfs.list.txt
    1,1 KB · Aufrufe: 169
  • dmesg.txt
    6,5 KB · Aufrufe: 162
Heute kam ein dickes Upgrade der Packete (418) wegen python-37 -> python-38. Mein Rechenknecht ist altersschwach, hat weder viel Festplattenspeicher (19 G - davon 6 frei) noch viel RAM (512 M). Filesystem ist ZFS. Habe in den Foren gelesen, daß dieser Fehler auftaucht, wenn zu wenig Arbeitsspeicher+Swap vorhanden ist, daß aber durch die Erhöhung der Swap-Partition die Installation der Pakete dann durchläuft.
Soweit ich das verstanden habe, ist doch die Swap-Partition bei ZFS dynamisch, oder? Sie müßte sich damit automatisch vergrößern.

Wäre für jede Hilfe sehr dankbar, will nicht den ganzen Rechner wieder neu aufsetzen, jetzt, wo er gerade so schön rund läuft.
Darf ich mal eine Frage stellen? Wäre es nicht besser sich einen besseren, preiswerten und evtl. sogar gebrauchten Rechner zu besorgen, mit wesentlich mehr Hauptspeicher und Plattenplatz? Den dann einrichten und Daten kopieren, die Du brauchst. Dann hast Du in Zukunft erstmal keine solchen Probleme mehr. Ja, ich gebe zu, das ist keine Antwort auf Deine Frage - aber doch ein pragmatischer Weg?? VG Norbert
 
Mein ältestes noch halbwegs direkt verwendetes Notebook ist (Thinkpad X31) von 2004 ... 17 Jahre alt und ich nehms nur noch als besseres "Terminal".

Es hat bereits 2GB Ram ... just saying ...
 
Neuere Hardware wäre sicherlich der beste Weg. Denn das nächste Update kommt bestimmt. Selbst, wenn wir dieses Update hinbekommen, ist die Frage, ob es bei nächsten Mal noch klappt. Aber zum Thema. Der nächste Schritt wäre viel mehr Swap rein. Notfalls von einem USB-Stick. Dann Geduld und hoffen, dass das Update durchläuft.

Von einem USB-Stick:
Code:
swapon /dev/daX

Aus einer Datei:
Code:
# Datei erstellen
truncate -s 2G /root/swap.img

# Zum Device machen
mdconfig -a -f /root/swap.img

# Und als Swap einhängen
swapon /dev/md0

Swap aus Dateien hat ein gewisses Deadlockrisiko, aber was solls. Wird schon klappen. Und wenn nicht, ist es kein Atomkraftwerkskontrollcomputer ;)
 
Aber probier mal den ARC zu limitieren, in der loader.conf vfs.zfs.arc_max="128M" (z.b.). Wie ZFS darauf reagiert kann ich dir aber nicht sagen. Dann natürlich ein Reboot.
Hab ich gemacht, zudem ein Swapfile angelegt von 4G, siehe RoboNuggies Anleitung. Leider bricht pkg upgrade trotzdem ab. Ich lösche jetzt noch /usr/ports, um mehr Platz zu bekommen, mal sehen, wie es weitergeht.
 
Darf ich mal eine Frage stellen? Wäre es nicht besser sich einen besseren, preiswerten und evtl. sogar gebrauchten Rechner zu besorgen, mit wesentlich mehr Hauptspeicher und Plattenplatz? Den dann einrichten und Daten kopieren, die Du brauchst. Dann hast Du in Zukunft erstmal keine solchen Probleme mehr. Ja, ich gebe zu, das ist keine Antwort auf Deine Frage - aber doch ein pragmatischer Weg?? VG Norbert
Danke der Nachfrage. Natürlich habe ich bessere Rechner. Ein ganzes Bündel. Mich reizt es einfach auszuprobieren, inwieweit ich das Teil noch nutzen kann. Und, sämtliche sogenannte schmale Linux-Versionen haben versagt (Puppy, antiX, Bunsenlabs), nur pures FreeBSD mit WindowMaker als Desktop macht den Rechner noch nutzbar. Und, bislang ging es ja wunderbar.
 
Ich weiß nicht wie gut das bei FreeBSD geht, aber wenn du nen Server/Nas irgendwo im netzwerk hast könntest du /usr/ports auf nen NFS Share oder so auslagern
 
Ich weiß nicht wie gut das bei FreeBSD geht, aber wenn du nen Server/Nas irgendwo im netzwerk hast könntest du /usr/ports auf nen NFS Share oder so auslagern
Das geht. Man kann dazu in der /etc/make.conf die Buildverzeichnisse umbiegen, sodass sie nicht mehr im Portstree liegen:

Code:
# Arbeitsverzeichnisse nach /usr/obj
WRKDIRPREFIX=/usr/obj

# Distfiles auch
DISTDIR=/usr/obj/distfiles
 
Der ZFS Tuning Guide im FreeBSD-Wiki ist in dem Zusammenhang vermutlich auch interessant. Da wird unter anderem erklärt, an welchen Stellschrauben man auf Ressourcenschwächeren Systemen drehen kann und auf welche Parameter man ein Auge haben sollte.

Das könnte dir auch im weiteren Betrieb weiterhelfen. ;-)
 
Danke der Nachfrage. Natürlich habe ich bessere Rechner. Ein ganzes Bündel. Mich reizt es einfach auszuprobieren, inwieweit ich das Teil noch nutzen kann. Und, sämtliche sogenannte schmale Linux-Versionen haben versagt (Puppy, antiX, Bunsenlabs), nur pures FreeBSD mit WindowMaker als Desktop macht den Rechner noch nutzbar. Und, bislang ging es ja wunderbar.

Ein netter Gedanke- besonders das FreeBSD da noch funzt!!! :) :) ich finde, dass wir (auch) in der IT zu einer Wegwerf-und-schnell-mach-Gesellschaft geworden sind :) Hauptsache bunt und Riesenbuttons. Sachen, die sich in den Bildschirm nachträglich reinschieben, viel unnötiges Zeug, das vom Wesentlichen ablenkt... Der Gedanke, alte Hardware zu nutzen - super! Ich nutze z.B. gerne ältere Supermicro Boards. Laufen prima! Einige davon haben noch reichlich Leistung... Viele Grüße aus Münster und einen schönen Tag Dir (und Euch allen), Norbert :)
 
Ein netter Gedanke- besonders das FreeBSD da noch funzt!!! :) :) ich finde, dass wir (auch) in der IT zu einer Wegwerf-und-schnell-mach-Gesellschaft geworden sind :) Hauptsache bunt und Riesenbuttons. Sachen, die sich in den Bildschirm nachträglich reinschieben, viel unnötiges Zeug, das vom Wesentlichen ablenkt... Der Gedanke, alte Hardware zu nutzen - super! Ich nutze z.B. gerne ältere Supermicro Boards. Laufen prima! Einige davon haben noch reichlich Leistung... Viele Grüße aus Münster und einen schönen Tag Dir (und Euch allen), Norbert :)
Ich bin dadurch auf viele interessante Sachverhalte gestoßen, zum Beispiel MD als Standarddateiformat für Dokumente zu verwenden und diese dann mit glow anzeigen zu können. Oder das Gopher- oder moderner das Gemini-Protokoll anstelle von HTTP für Internetseiten zu verwenden. Es ist erstaunlich, wie viele gute Programme mit schmalem Fußabdruck es gibt, wenn man eben nicht mit RAM und Festplattenspeicher herumaasen kann.
XFig für Vektorgrafiken, mtPaint zur Bildbearbeitung. Oder Kakoune, Calcurse, gopher, amfora, nnn, mc, feh usw. für das Terminal. Ausnehmend gut gefällt mir WordGrinder.
 
Zuletzt bearbeitet:
Also wenn weniger ARC und mehr Swap nicht hilft bin ich auch überfragt. Was du noch probieren könntest: Erstmal das neue Python installieren (sollte sich ja problemlos zum alten parallel installieren lassen) und dann die updates möglichst einzeln einspielen.
 
War mir dann letztendlich zu viel Aufwand, habe den Rechner komplett neu aufgesetzt.
 
Schon mit UFS sind 512MB nur genug RAM für eine kleine VM, die nicht viel machen soll.
Ich habe diesmal bei der Installation einfach 4GB Swap verordnet, und die Maschine rennt merklich schneller. Und, ich entdecke immer mehr schlanke Software für die verschiedensten Aufgaben, muß sagen, daß ich begeistert bin, was es alles gibt!
Diesmal habe ich WindowMaker mittels desktop-installer installiert und bin erstaunt, wie gut alles installiert wurde. Habe auch eine Menge nützlicher CLI-Programme gefunden, die zuverlässig ihren Dienst tun, sodaß ich mich nicht mit aufgeblähten graphischen Anwendungen herumschlagen muß, zumal ich den Rechner oft via ssh nutze.
 
Zuletzt bearbeitet:
Zurück
Oben