[CFT] pkg_libchk modernisiert

Kamikaze

Warrior of Sunlight
Teammitglied
Ich habe auf dem 31c3 bpkg_libchk neu geschrieben, weil da ja schon eine ganze Weile nichts mehr funktioniert. Jetzt würde ich mich über Tester freuen:
https://sourceforge.net/p/bsdadminscripts/bsda2

Einen Snapshot gibt es hier:
https://sourceforge.net/p/bsdadminscripts/bsda2/ci/default/tarball

Es ist nicht notwendig das Script zu installieren. Das kann einfach aus dem Ordner ausgeführt werden.

Es läuft deutlich schneller (bei mir Faktor 6) als das alte Script. Die Parameter -r und -R wurden analog zu pkg info von -d und -r abgelöst.

Wenn eine problematische Bibliothek ausgetauscht wurde:
Code:
./pkg_libchk -r png

Wenn man den allgemeinen Gesundheitszustand wissen will:
Code:
./pkg_libchk
 
FreeBSD/amd64 10.1-RELEASE-p3:
Die neue Version ist tatsächlich "verdammt" schnell. Es wirft hier keinen einzigen defekten Port aus. Nichtmal den üblichen verdächtigen: LibreOffice. Vermutlich ist das gewollt.

Danke für die Arbeit! Gibt es auch (irgendwann) eine neue Version von pkg_validate?
 
Ja, ich denke das werde ich auch machen. pkg_validate ist ein ziemlich simples Werkzeug.

Bei mir schmeißt libreoffice auch nichts, weder mit der alten, noch der neuen Version von pkg_libchk.

Ich habe das Skript mit diversen Sabotageakten dazu bewegt output zu erzeugen.

Eine libmap.conf anlegen und Libraries ins Nirvana umleiten oder umbenennen.
 
LibreOffice ist ein Sonderfall, da es viele Bibliotheken nicht normal linkt. Stattdessen öffnet es sie per dlopen(). Für ldd(1) und damit pkg_libchk sind diese Abhängigkeiten damit unsichtbar.
 
pkg_libchk war vorher für mich schon schnell und jetzt ist es noch viel schneller:

root@(0):~/mytmp/bsdadminscripts-bsda2-6fa7c0fcbd5bdd8afd15a554c26c4034351881bf/src$ time pkg_libchk
44.205u 148.486s 0:44.87 429.4% 134+168k 448+1025io 0pf+0w

root@(0):~/mytmp/bsdadminscripts-bsda2-6fa7c0fcbd5bdd8afd15a554c26c4034351881bf/src$ time ./pkg_libchk
6.570u 11.631s 0:08.75 208.0% 125+173k 10+247io 0pf+0w

Danke für deine Arbeit!

---
$ pkg info | wc -l
247

$ uname -m -r
10.1-RELEASE amd64

$ env
TERM=xterm-256color
MM_CHARSET=UTF-8
LANG=en_US.UTF-8
 
LibreOffice ist ein Sonderfall, da es viele Bibliotheken nicht normal linkt. Stattdessen öffnet es sie per dlopen(). Für ldd(1) und damit pkg_libchk sind diese Abhängigkeiten damit unsichtbar.
Das ist ja nicht verkehrt. Man verwendet dlopen ja nur aus einem Grund. Nämlich dem, dass man den Fall wenn die Bibliothek nicht da ist ordentlich behandelt.
 
Seit dem ich den Thread hier geöffnet habe wurden einige Fehler behoben:

Duplikate, die durch Mehrfachnennung von Paketen oder den -d und -r Optionen entstehen können, werden jetzt gefiltert. Mit etwas böswilligen Parametern kam ich da auf über 140000, was natürlich knallt sobald man die Liste einem Kommando als Parameter übergibt, mal ganz davon abgesehen, dass es unnötig Rechenzeit verschwendet.

Bei Terminals mit mehr als 255 Zeichen Breite kam es bei der Statusanzeige zu Fehlern, die zu einer Endlosschleife führten. Ich bin da in ein hartes Limit von sed reingelaufen und musste an einigen Stellen auf awk umsteigen.

In bestimmten Fällen kam es beim Abbrechen mit SIGINT (Ctrl-C) dazu, dass eine Datei /tmp/libchk.… liegenblieb, die als asynchroner FIFO für die Prozesskommunikation dient. Das Problem konnte ich durch eine Änderung am Garbage Collector beheben. Der Garbage Collector wartet jetzt einfach darauf, dass alle Kindprozesse sterben, damit sie nicht auf Ressourcen zugreifen, nachdem diese eigentlich schon abgeräumt wurden.
 
Ich habe gerade noch mal ein Update gepusht, das ein Memory-Leak fixt, was sich erstaunlich deutlich auf die Performance auswirkt.

Damit bin ich an dem Punkt angekommen, an dem die Status-Anzeige etwa 50% der Laufzeit ausmacht (wenn die Daten im Cache oder auf einer schnellen SSD sind). Wer sich die Zeit sparen will kann die -c Option verwenden. Wenn die Daten von einer magnetischen Platte gelesen werden macht das eher wenig Unterschied und man ist bloß frustriert, weil man den Fortschritt nicht sieht.
 
Habs auch mal getestet und es läuft wirklich sehr gut. Danke dafür. Ich habe nur zwei Fragen/Anmerkungen:
Code:
root@...b328bd86f0203c427a254728bd2eb7748/src # ./pkg_libchk --help
pkg_libchk v1.99
usage:  [-a] [-c] [-d] [-h] [-jN] [-m] [-n] [-o] [-q] [-r] [-v] [packages]
Wie kann ich eine Hilfe anzeigen? Welcher Parameter macht was?

Zweitens wäre eine "man" Page nicht schlecht ;) Die kannst du wirklich sehr sehr einfach mit sphinx erstellen. [1]

Danke Gruss

[1] http://sphinx-doc.org/
 
Manpage ist dabei.

Edit:
nroff -mdoc src/pkg_libchk.1 | less -r
Oder für Faule:
man src/pkg_libchk.1

Wobei ersteres schöner gerendert wird.
 
Zuletzt bearbeitet:
So jetzt habe ich es endlich hin bekommen Named pipes korrekt zu verwenden. Damit fällt der Overhead durch Polling auf eine Datei im Job dispatcher weg.

Das verringert den Overhead und beschleunigt die Sache auf Single-Core Maschine oder im -j1 oder -j2 Betrieb noch mal etwas.

Der Trick war übrigens einen I/O File Descriptor [n]<> zum Zugriff auf die Named pipe zu verwenden. So einen habe ich noch nie in freier Wildbahn gesehen. Die nächste Hürde war, dass ich das mit dem Builtin read auslesen muss, damit der Deskriptor nicht geschlossen wird. Wenn das passiert kann man Daten zwar noch auslesen, wenn welche in der Pipe liegen, aber wenn nicht bekommt man ein EOF, so dass der Prozess nicht blockiert.

Außerdem hat head -n1 (was ich zuerst verwendet habe) anscheinend mehr Daten ausgelesen als es am Schluss ausgibt. So dass diese verloren gehen, weil die natürlich nur ein mal aus der Pipe kommen. Daran bin ich schon 2 mal gescheitert.
 
Zurück
Oben