[CFT] bsda2

Kamikaze

Warrior of Sunlight
Teammitglied
Hallo,

wer meine alten bsdadminscripts noch kennt freut sich vielleicht. Ich suche Tester für mein Nachfolgeprojekt.

Mitgeliefert werden nur noch buildflags, pkg_libchk und distviper. Alle anderen Skripte halte ich für obsolet.

Die Sourcen bekommt man hier:
https://github.com/lonkamikaze/bsda2/archive/0.0.999.tar.gz

ACHTUNG
Vorher auf jeden Fall die alten bsdadminscripts deinstallieren, da sonst Dateien in /usr/local/sbin überschrieben werden.


Zur Installation einfach:
Code:
# fetch https://github.com/lonkamikaze/bsda2/archive/0.0.999.tar.gz
# tar -xf bsda2-0.0.999.tar.gz
# cd bsda2-0.0.999
# ./install.sh

Zur Deinstallation einfach:
Code:
# ./deinstall.sh
 
Zuletzt bearbeitet:
So weit wird das jetzt nicht fragmentieren, dass ich zwischen den Releases snapshots veröffentliche.
 
Ich habe gerade die aktuellste Version 0.1.1 getestet. Beim Ausführen von pkg_libchk -q erhalte ich folgende Fehlermeldung (nach einer gewissen Zeit):

eval: 1: Syntax error: Unterminated quoted string
eval: 1: Syntax error: Error in command substitution

Was kann ich dir liefern, damit es dir hilft?
 
Ok.. Reproduzierbar ist das scheinbar nicht. Ich habe es jetzt nochmal laufen lassen und erhalte die Fehlermeldung nicht mehr. Merkwürdig finde ich, dass ich jetzt wieder sehr häufig die Meldung "ELF binary type "0" not known." erhalte. Ich dachte eigentlich, dass ich die Meldung bekomme, da linux.ko nicht geladen war. Nach einem "kldload linux" und einem anschließenden Aufruf von pkg_libchk -q kam die "eval" Meldung. Nach einem zweiten Aufruf, wie gesagt, nicht mehr.
 
Beim Aufruf von pkg_libchk ohne Parameter (auch nicht reproduzierbar):
gvfs-1.26.3_2: /usr/local/libexec/gvfsd-cdda misses libcam.so.6
Jobs done: 464 of 1271eval: f94f5_0_: not found
/usr/local/sbin/pkg_libchk: f94f5_0_.getSline: not found
/usr/local/sbin/pkg_libchk: f94f5_0_.getPkg: not found
/usr/local/sbin/pkg_libchk: f94f5_0_.getMisses: not found
/usr/local/sbin/pkg_libchk: f94f5_0_.delete: not found
/usr/local/sbin/pkg_libchk: arithmetic expression: expecting EOF: "libXau-1.0.8_3"
 
Das ist schon ziemlich bizarr.

Wenn ein Fehler reproduzierbar ist, kann man das mit sh -x ausführen und im Output nach der Fehlermeldung suchen.

Außerdem kannst Du pkg_libchk mit dem -c Flag ausführen, damit solche Fehler nicht mit den Statusanzeigen kollidieren. Vorausgesetzt die Statusanzeige ich das Problem.
 
Ich teste und berichte weiter... Aktuell baue ich einfach mal alle Ports neu, die pkg_libchk anmeckert. Für den Fall, dass es wichtig ist: Das ganze läuft auf einem 11.0-RELEASE-p7/amd64 in tmux.

Ich habe nun alle Ports die betroffen waren, neu gebaut. Zusätzlich habe ich - weil ich den Fehler nicht wegbekommen habe - mal alle linux-c6-Ports gelöscht. Jetzt läuft das Programm sauber durch.

Die Geschwindigkeit im Vergleich zur alten Version ist schon ziemlich beeindruckend! Danke für deine Arbeit!
 
In den linux-c6 Ports fehlen schlicht einige Libraries. Aber alles was man braucht geht, also kannst Du die ruhig benutzen. Die Fehler sind aber richtige Fehler, deshalb baue ich da auch keine Ausnahmen für ein.
 
Moin,
ich habe die linux-c6 Ports nicht wegen der fehlenden Libs deinstalliert sondern wegen der 100-fachen Meldung:
ELF binary type "0" not known.
Die Meldung kam so oft, dass pkg_libchk gar nicht angezeigt hat, welcher Port "betroffen" ist. Lass mich es laienhaft ausdrücken: pkg_libchk wollte linux-c6-foobar prüfen. Der Kernel konnte wegen nicht geladener Linuxunterstützung das aber gar nicht prüfen und hat nicht gesagt "die lib fehlt" (vielleicht fehlt ja gar keine) sondern "mit dieser ELF binary kann ich nichts anfangen". Die Fehlermeldung hat auch gar nichts mit pkg_libchk zu tun, ich hatte die auch bei der Deinstallation erhalten (weil keine Linuxunterstützung geladen war).

Inzwischen weiß ich, dass ich wohl hätte linux64.ko laden müssen, ich hatte aber nur linux.ko geladen.
 
Ah, das hatte ich noch nicht gesehen. Mal sehen ob ich das irgendwie händeln kann.

Update:
Anscheinend wird der Fehler vom Kernel an der Shell vorbei direkt ins Terminal geschickt. Jetzt habe ich natürlich keine Ahnung, wie ich das umleite.
 
Zuletzt bearbeitet:
Ich habe gerade die aktuellste Version 0.1.1 getestet. Beim Ausführen von pkg_libchk -q erhalte ich folgende Fehlermeldung (nach einer gewissen Zeit):
Code:
eval: 1: Syntax error: Unterminated quoted string
eval: 1: Syntax error: Error in command substitution
Beim Aufruf von pkg_libchk ohne Parameter (auch nicht reproduzierbar):
Code:
gvfs-1.26.3_2: /usr/local/libexec/gvfsd-cdda misses libcam.so.6
Jobs done: 464 of 1271eval: f94f5_0_: not found
/usr/local/sbin/pkg_libchk: f94f5_0_.getSline: not found
/usr/local/sbin/pkg_libchk: f94f5_0_.getPkg: not found
/usr/local/sbin/pkg_libchk: f94f5_0_.getMisses: not found
/usr/local/sbin/pkg_libchk: f94f5_0_.delete: not found
/usr/local/sbin/pkg_libchk: arithmetic expression: expecting EOF: "libXau-1.0.8_3"

Die beiden Fehler sehen für mich wie ein IPC Problem aus. In den letzten Tagen hatte ich das auch 1 mal, konnte es aber nicht reproduzieren.

pkg_libchk hat folgende Prozesse:

- Die Session (der Hauptprozess)
- Job Prozesse (die jeweils ein Paket abarbeiten)
- Und ein Terminal Prozess, der für die Ausgabe, Statuszeilen etc. zuständig ist

Die Job Prozesse liefern über ein Named-Pipe Daten an die Session, die Session liefert Daten über eine Named-Pipe an den Terminal Prozess.

Meine These ist jetzt:

- Mindestens 2 Jobprozesse schreiben gleichzeitig in die Pipe
- Mindestens einer der Prozesse hat eine Nachricht, die länger als der output-Puffer (oder halt irgendein beteiligter Puffer) des Prozesses ist

Dann rutscht eine Nachricht quasi zwischen 2 Fragmente einer anderen Nachricht.

Ein Lösungsansatz den ich heute Abend mal testen werde ist write-Locking einzubauen. Die Idee ist eine 2. named-Pipe für das Locking zu verwenden:

- In der Lock-Pipe liegt initial ein Byte zum Lesen
- Wenn ein Prozess in die Msg-Pipe schreiben will:
-- Liest er das Byte aus der Lock-Pipe
-- Schreibt in die Msg-Pipe
-- Schreibt ein neues Byte in die Lock-Pipe

Da die Pipe das Byte nur 1 mal ausspuckt wird ein anderer Prozess der versucht das Byte aus der Lock-Pipe zu lesen schlafen gelegt bis der andere Prozess das neue Byte in die Pipe geschrieben hat. Das ganze basiert natürlich auf der Annahme, dass ein 1-Byte write atomar ist.
 
Leicht OT:

Auf den Rechnern, auf denen ich bsdadminscripts (V1) aus den Ports installiert hatte, bekomme ich bei einem pkg delete bsdadminscripts folgende Meldungen:

pkg: /usr/local/sbin/rcstop different from original checksum, not removing
[foo.bar] [1/1] Deleting files for bsdadminscripts-6.1.1_8: 100%
Das ist jetzt natürlich nur ein Auszug. Ich bekomme es für jedes File. pkg nutze ich nur selten. Auf dem einen Rechner auf dem ich es nutze, bekam ich die Meldung nicht...

Danke für deine Arbeit! Endlich ist V2 in den Ports! :)
 
Code:
     Since the possibility to run parallel jobs was introduced, output no
     longer is sorted. If you find that annoying you can run:

           pkg_libchk -j1

     Of course there is a heavy performance penalty especially on systems with
     several CPU cores.

     Another way around this is to pipe output into sort(1):

           pkg_libhck | sort

     This will run faster, but output will be printed after the script has
     terminated.

pkg_libhck | sort

Typo in der man gefunden :)
 
Code:
     Since the possibility to run parallel jobs was introduced, output no
     longer is sorted. If you find that annoying you can run:

           pkg_libchk -j1

     Of course there is a heavy performance penalty especially on systems with
     several CPU cores.

     Another way around this is to pipe output into sort(1):

           pkg_libhck | sort

     This will run faster, but output will be printed after the script has
     terminated.

pkg_libhck | sort

Typo in der man gefunden :)
Muss die alte manual page sein. Das alte bsadminscripts ist ziemlich ranzig. Du willst bsdadminscripts2.
 
ahja, das kann natürlich sein. Ich sitze auf quarterly und habe das eine Paket installiert, das es da gab.
Ich nutze vor allem distviper und pkg_libchk und eigentlich brauche ich da keine man page mehr dazu. Weil ich aber beide nicht sehr häufig nutzen muss (da ich quasi nur noch Pakete einsetze), schaue ich gerne zuvor nochmal nach. Bestimmt habe ich diesen Typo schon X-mal überlesen, aber heute hatte ich das per copy_n_paste benutzt und da ist mir das halt aufgefallen.
Wenn du eine neue man page geschrieben hast, hat sich das ja erledigt.
 
Zurück
Oben