Re: Suche Debughilfe: child never returns from fork?

On Thu, Apr 10, 2008 at 08:52:54PM +0000, Peter Much wrote:
> <ticso(at)cicely.de> aka Bernd Walter schrieb
> mit Datum Wed, 9 Apr 2008 13:43:32 +0200 in m2n.de.fbsd.questions:
>
> |> Gute Frage. Die wurden unmittelbar vorher mit pipe() beschafft.
> |
> |Pipes funktionieren unter FreeBSD sehr viels anders, als unter Linux.
>
> Tja, kann daran liegen, oder an was anderem. Ich bin glaub ich
> auf einer Spur ums einzugrenzen - ich habs durch irgendeinen Zufall
> geschafft dass es häufiger auftritt, und dann eine Option
> gefunden mit der man (überflüssige?) Features zum Debuggen
> abschalten kann, und dann scheint es nicht mehr aufzutreten...

Na immerhin.
Denoch hat das Programm etliche fundamentale Fehler eingebaut, die
dich jederzeit per Zufall sehr hart treffen können.
Eine Backupsoftware, der man nicht trauen kann ist nichts wert.

> |Die Suche nach dem Schuldigen ist manchmal ausreichend.
>
> Jein. Das sehe ich bei Freeware etwas anders. Zum einen fasse
> ich sie als Geschenk auf; auch als ein Geschenk, das aus einer
> Inspiration kommt: ein neues Programmkonzept kann man ja nicht
> rein rational finden, sondern da gehört auch Genius dazu, Eingebung.
> Und die "Geschenke der Götter" (wenn ich das mal so nennen darf)
> sind höchst individuell, und wenn ein Mensch das dann so umsetzt
> wie er es eben tut, dann nur deshalb weil er es besser nicht
> vermochte. Das ist für mich kein Grund, den Genius darin nicht
> wertzuschätzen.

Computerviren sind auch "Geschenke".
Bist du froh darüber?
Vermutlich nicht.
Ich bin mir sicher, dass die Bacula Leute keine bösen Absichten hatten,
aber denoch bedeutet eine unzuverlässige Backupsoftware auch ein sehr
hohes wirtschaftliches Risiko und kann schnell sehr viel teurer sein
als kostenlos.

> |Wenn man z.B. erkennt, dass der Programmcode ohne ausreichend
> |Hintergrundwissen geschrieben wurde, dann kann es einen kompletten
> |review erfordern oder dazu führen die Software nicht einzusetzen.
>
> Okay, weg vom philosophischen, hin zum pragmatischen. Natürlich
> muss man da eine Evaluierung machen. Das ist aber eine mehrschichtige
> Angelegenheit, wo zB neben den technischen Aspekten auch die
> Dringlichkeit des Bedarfs und die Verfügbarkeit von Alternativen
> mit eingehen.

Gut - wenn du bei deiner Evaluierung das Thema "vertrauenswürdig" nicht
so hoch einschätzt.
Oder die zum Teil harsträubenden Fehler, die ja selbst dir als nicht
so harter UNIX-Programmierer, wie so manche andere hier auf der Liste,
bereits aufgefallen sind, als unbedenklich einstufen willst.
Nun - dann kannst du die Software ja auch einsetzen.

> Was nun konkret Bacula angeht -
> es wundert mich nicht dass es, wie Du weiter unten schreibst
> "durch unsauberkeiten aufgefallen ist" - das betrifft etliche
> Konstrukte im Code und Layout, die teilweise unbelastet von guter
> Unix-Tradition und teilweise mit kleinen Fehlern garniert sind.

Gut, aber einige der Probleme haben ja nichts mit UNIX zu tun,
sondern gehören zu den absoluten Grundlagen der Programmierung
auf jeden OS und in nahezu jeder Sprache.

> Gleichzeitig ist aber der Programmierstil ein ausgesprochen
> schöner und übersichtlicher, die Codeschreibe sehr ordentlich und
> die inline-Dokumentation hab ich noch fast nur in Schulungsprojekten
> so vorbildlich gesehen. Die Transparenz und Normalisierung des
> DB-Layout kann man auch nur als perfekt bezeichnen.

Was bei mir nur das Gefühl bringt, dass es sich um Theoretiker ohne
Erfahrung handelt.

> Und von der Seite her ist es gar nicht so schlimm, da die Sachen
> zu fixen - weil man sich dabei angenehm zurechtfindet. (Bei
> Freeware gibts im Entscheidungsportfolio eben die zusätzliche
> Option: <ich kanns selber warten/fixen>.)

Natürlich - aber du hast reichlich Fehler gefunden, ohne intensiv
alles geprüft zu haben, was darauf hindeutet, dass es noch sehr viel
mehr gravierende Fehler geben wird.

> Und die andere Seite sind eben die Funktionen die es bietet.

Gut, aber die erste Funktion, die ich von einer Backupsoftware
erwarte, ist zuverlässig zu sein.
Ein kaputtes Backup wirst du erst beim restore bemerken und
nicht alles muss bei Stichproben auffallen.
Was nutzt mir z.B. ein Taschenrechner, der MP3s abspielen kann,
aber bei dem Zweifel angebracht sind, dass der immer richtig
addiert?
Klar - als MP3-Spieler kann man den möglicherweise gebrauchen,
aber meine Berechnungen würde ich dann doch eher nicht damit
machen wollen.

> Da sind eine Menge Dinge recht funktional angelegt bzw. vorverdrahtet,
> die es anderswo m.W. überhaupt nicht gibt, und die es mit
> überschaubarem Aufwand ermöglichen können, nicht bloß ein schnödes
> Backup ("write once, read never"), sondern eine Art Archiv-Management
> zu machen.
> Da ist eine Versatilität in der Makrostruktur. Und in der Mikrostruktur
> ist diese Versatilität ebenfalls vorhanden - zwei Beispiele: jedes
> sinnvolle Systembackup schreibt irgendeine Art Zusammenfassung
> irgendwo in eine Datei, und diese Dateien solltest du offline
> bereithalten für den fall dass das ganze System verloren ist und
> du ohne Datenbankzugriff neu aufsetzen muss - weil du sonst überhaupt
> nicht weißt was wo auf den Bändern ist. (Systematisches Desaster
> Recovery ist nochmal was anderes, das mein ich hier nicht.)
> Und da ist immer das Problem: wohin mit dem Scheiss, wo er weit
> genug vom Rechner weg ist _und_ immer mit aktualisiert wird, und
> das natürlich möglichst vollautomatisch ohne extra Arbeitsschritt.
> Bacula hilft einem dabei nicht, aber: es behindert einen auch nicht
> dabei! - sondern erlaubt einfach für jeden Backupjob individuell ein
> System-Kommando anzugeben, wo es das Teil hinliefert (vorgeschlagen
> wird mail). Bei mir wars dann Pnews (netnews) - weil das hab ich
> eh laufen für die Mailinglists, das ist strukturiert, das repliziert
> sich automatisch auf mehrere Rechner oder auch offsite, und das
> expired sich automatisch. Einmal gemacht, und *nie* mehr Arbeit damit.:)
> Und die meisten Softwareprodukte die ich so kenne, die stehen einem bei
> dieser Art perfekter Lösungen eher im Weg als dass sie dabei
> (zurückhaltend und doch wirksam) unterstützen.
>
> Anderes Beispiel: ich lasse meine inkrementellen Backups jetzt
> alle 10 minuten machen, und habe damit einen funktionalen Ersatz
> für eine undelete-Funktion und für ein autoversioning filesystem:
> ich werde wahrscheinlich nie mehr eine .orig Datei anlegen brauchen
> wenn ich für irgendwas eine neue Konfiguration ausprobiere.

Kann ich mit ZFS auch machen.
Snapshot anlegen und diff als stream anfordern.
Den Stream kann ich auf Band schreiben und/oder auf einem anderen System
direkt importieren.
Den Replikationsserver kann ich auch gleich als Reserve-Rechner benutzen
und natürlich jegliches File wiederherstellen.
Für mich haben Bänder ohnehin ausgedient - einfach nciht mehr
wirtschaftlich genug.
Es gibt zwar immer noch Situationen, wo Bänder angezeigt sind, aber ich
habe damit in den letzten Jahren nichts mehr zu tun gehabt.
Meinen letzten Streamer habe ich vor ca einem Jahr endgültig außer
Betrieb genommen, weil die Medienkapazität halt nicht mit den
Anforderungen gewachsen war und die Medienpreise auch zu hoch waren.
Ich selber setze inzwischen stark auf ZFS als Sicherungssystem, auch
wenn die Originaldaten auf einem anderen Filesystem liegen.
Alles, was ich brauche ist eine Software, um Daten zuverlässig differentiell
auf den ZFS-Server zu spiegeln, der dann davon Snapshots macht.
ACL gehen damit zwar zur Zeit nicht, aber kann Bacula ACL?

> Bacula macht dabei keine Probleme mit dem Footprint, und hat keine
> Probleme die tausende anfallenden Backups handzuhaben. Mit der
> Parallelisierung gab es ein bischen Probleme; die waren behebbar.
>
> Wenn Du mir irgendwas anderes sagst, was das leistet, da bin ich
> neugierig.
>
> Unterm Strich halte ich das Teil für durchaus reparabel (ob es dazu
> kommt hängt natürlich von der Dynamik der Userbase ab) und halte es
> von der Funktionalität für einen wertvollen Gewinn für die Freeware.
> Ideal wär natürlich, wenn eine Anzahl gestandene Unixer Interesse
> daran finden und gemeinsam ein bischen aufräumen würden - es ist
> schliesslich in der OpenDomain, d.h. es gibt genaugenommen niemanden
> auf den man zeigen könnte ->der schuld dran wäre dass es so ist wie
> es ist - außer auf sich selber weil mans noch nicht besser gemacht
> hat. ;-))

Ich behaupte ja nicht, dass es nicht reparabel ist, aber die
Vergangenheit hat da eine Gewisse Lernresistenz gezeigt.
Ich erinnere mich daran, dass die lange (oder immer noch?) nicht
zuverlässig mit FreeBSD auf Bändern schreiben konnten und Hinweise auf
deren Fehler wurden schlicht ignoriert.

> |> Muss ich sagen, dass ich von 6.3 nicht übermäßig begeistert bin?
> |> (Ich bau seit vier Monaten Bugs raus. Aus *allem* - Ports, User,
> |> Kernel, Scripts, aus meinem Kopf;), ...)
> |
> |Ich kann mich nicht an sonderlich viel erinnern.
>
> Naja, ich hab zwei produktive Rechner straightforward von 5.5 auf
> 6.3 upgraded und hatte als Ergebnis drei Kernelpanics beim Boot.
> Das macht 150%. (Eine konnte ich fixen, eine ist zwischenzeitlich
> in 7 gefixt worden, und eine ist pending.)

Das ist natürlich schlecht, aber deckt sich nicht mit meiner Erfahrung.
Offensichtlich hast du einfach nur Pech gehabt.

> |Kaskadierte Sighandler sind nicht ohne.
>
> Das hat man berücksichtigt und alle Sighandler mit sigfillset()
> versorgt. :-/

Keine gute Idee.

> |Ich verstehe aber auch den ganzen Sinn des Abort-Handlers nicht.
>
> Der "Sinn" liegt darin, dass man einen backtrace produziert um
> ihn dem Entwickler zuzumailen.

abort(3) - abgesehen davon erzeugt ein segfault ohnehin default bereits
einen core.
Mit dieser Funktion schickt das Programm letzlich einen SIGABRT an sich
selber.
Einen SIGABRT kannst du auch per kill(1) und sogar top an einen Prozess
schicken, um einen coredump zu produzieren.
Das funktioniert aber nur, wenn das Programm das eben nicht verhindert.
Ich verstehe nicht, warum so manche Programme klüger sein wollen, als
die Leute, die das schon seit Jahrzenten auf allen UNIX Systemen
erfolgreich anders machen.
Warum sollte auch jedes Programm anders debugged werden?
Der Sinn das mit jedem Programm gleich zu handhaben liegt doch gerade
darin, dass man alles mit den gleichen mitteln machen kann.

> |> (*) Andere Frage:
> |> Ich versteh nicht warum alle welt meint man solle erstmal
> |> "makeoptions DEBUG=-g" einschalten - ich hab beim Probieren
> |> (bzgl. kern/122126) erlebt, dass das bewirkt, dass der Kernel
> |> im falle einer panic gleich mehrere davon macht und dann nicht
> |> mehr rebootet sondern steckenbleibt - also KDB und KDB_UNATTENDED
> |> funktioniert dann nicht mehr.
> |
> |-g bewirkt mit Sicherheits nichts von dem.
> |Alles, was passiert ist, dass Debuginformationen mitgeschrieben
> |werden, z.B. von welcher Programmzeile welcher Code kommt.
> |Das wird aber nebenher geschrieben und steckt zwar im Binary drin,
> |wird aber nicht in den Speicher geladen.
> |Man benutzt das beim Kernel ausschließlich zum analysieren von
> |Crashdumps.
>
> Tja, das stimmt nur leider nicht. :(

Doch - das mit dem -g stimmt genau so.

> Es ist definitiv so, dass mein Kernel mit einer bestimmten
> Netzwerkkarte eine Panic produziert. Und dann kommt das bekannte
> "rebooting in 3600 seconds - press any key to reboot" eben genau
> so wie ich den Kernel konfiguriert hab (mit KDB, DDB, KDB UNATTENDED
> und PANIC REBOOT WAIT TIME) und wie ich es für ggfs. operatorlosen
> Betrieb haben will.

Mag ja sein, aber das hat nichts mit -g zu tun, sondern evtl mit
Optionen, die auch tatsächlich im Programmcode landen.

> Und wenn ich als /einzige/ Änderung dieses "makeoptions DEBUG=-g"
> im Kernelconfig einschalte und neu baue, dann kommen _mehrere_
> Panics und der Kernel friert ein (übrigens genau so wie es auch der
> GENERIC Kernel tut der diese Option auch hat - wodurch sich ein
> bloßer Compilierfehler eher ausschließt).

Das kann andere Ursachen haben.
Z.B kaputtes RAM, weil die -g Daten ja vom loader extrahiert werden
müssen, oder sonst was.
Unabhängig davon würde ich stark vermuten, dass du nur durch Zufall die
Symptome beseitigt hast, aber nicht den Fehler.

> Und ich bin grad am überlegen ob ich diese Netzwerkkarte in einen
> extra Rechner einbaue, dessen Console via Nullmodem in ein jail
> lege, und dann kann wer mag sich dran spielen. Mich hats nämlich
> eigentlich inzwischen genug genervt...

Was ist denn das für einer Karte?

-- 
B.Walter <bernd@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message