Re: Suche Debughilfe: child never returns from fork?

<ticso(at)cicely.de> aka Bernd Walter schrieb
mit Datum Fri, 11 Apr 2008 03:49:07 +0200 in m2n.de.fbsd.questions:

|> 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.

Ne, das wars leider nicht. Hat zwar auf der schnelleren Maschine
geholfen, dafür sind sie dann auf der langsameren verstärkt
aufgetreten.
Ich hab dann die Suche aufgegeben und das Problem einfach auf die
(ganz unsportliche) hau-ruck Methode beseitigt: sleep(1) im Parent
nach dem fork(). Das hilft - aber das war mir eigentlich von
vorneherein klar, dass es ein Timing-Issue ist - und da ich am
Client nix drehen kann weil der gar nicht erst aus dem fork()
rauskommt, muss es am Parent liegen.

Jetzt könnte man natürlich immer noch fragen, was genau da falsch
läuft. Und ich würde dabei auch nicht darauf wetten, dass der Fehler
zwingend in der Anwendung liegen muss...

|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.

Es gibt keine Software der man vorbehaltlos trauen kann.

|Computerviren sind auch "Geschenke".
|Bist du froh darüber?

Computerviren sind genauso wie andere Viren etwas was nunmal
existiert, und es ist _mein_ Job vorzubeugen - indem ich zB ein
OS verwende, das bei sachgemäßer Handhabung kaum welche kriegen dürfte.

|> 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.

Unter pragmatischen Gesichtspunkten ist das für mich durchaus
verhältnismäßig vertrauenswürdig.
Wenn Du Dich nämlich mal ein bischen in der real existierenden
gewerblichen Datentechnik umschaust, dann wird Dir wahrscheinlich
auffallen dass das was dort vertrieben wird durchaus nicht besser
sein muss als zB Bacula, sondern du vor dieser Einsicht lediglich
dadurch geschützt wirst, dass du die Source gar nicht erst in die
finger kriegst.
Der wesentliche Unterschied ist dann, dass Du dort viel Geld
dafür bezahlen kannst - dieses Geld wird aber weniger dazu verwendet,
besseren Code zu fabrizieren - sondern um im Problemfall reichlich
Rechtsanwälte engagieren zu können falls man gegen Dich prozessieren
muss - denn so lassen sich im Ernstfall die Probleme auch beseitigen.

Deine Ideale von kompetenter portabler Programmierung sind ja
durchaus lobenswert, und an sich rennst Du damit bei mir eh offene
Türen ein - nur sieht es in der wirklichen Welt eben ziemlich anders
aus: Branchengrößen wie zB SAP schreiben Dir nicht nur das OS,
sondern auch Version, Release und ggfs. sogar den Patchlevel ganz
genau vor, unter dem ihre Soft verwendet werden kann.
Denen kann mithin wurscht sein, ob die Soft portabel programmiert
ist - die Konfiguration ist dann einfach "nicht supportet".

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

Mein Eindruck -und ich weiß ja *wo* ich die Fehler gefunden hab-
ist insoweit, dass man da schon sehr viel Aufmerksamkeit darauf
verwendet, dass die Backups intakt sind.
Es sieht, um bei dem Beispiel zu bleiben, eher so aus, dass
es dann beim MP3-abspielen einen Haufen wilde Fehler gibt.
Anderenfalls, wenn mir nicht eben das aufgefallen wäre, hätte
ich die Software auch recht schnell abgehakt.
Und dass ich durchaus zuversichtlich bin, liegt auch mit an meinem
spezifischen Nutzungsprofil: ich benutze nicht nur das Backup,
sondern auch das Restore - ich bin nicht auf Stichproben beschränkt.

|Kann ich mit ZFS auch machen.
|Snapshot anlegen und diff als stream anfordern.

Hae?? Das ist doch was völlig anderes und hat überhaupt nichts mit
einem Backup zu tun.
Wenn es sich in Deinem Nutzungsprofil so darstellt, dass dieses ZFS
bestimmte Features ermöglicht, die ich in einem Backuptool willkommen
heiße, dann ist das interessant - aber eine Vergleichbarkeit sehe
ich da nirgens gegeben.
Ich für meinen Teil war froh, dass ich auf filesystem-basierte
Redundanz dank Bacula jetzt weitgehend verzichten kann, weil ich
mit Bacula gezielt die Dateipfade auswählen kann, die wichtig sind.

Und ich hab mal einen Blick auf ZFS geworfen, und nicht gesehen wozu
ich es brauchen könnte: ich hab jetzt schon gvinum und geom, die
leider nicht miteinander können - da brauch ich nicht noch ein
drittes.
Ausserdem: festplattenbasierte Redundanz bedeutet, dass ich, um
nur ein einziges Byte zu schreiben, dazu zwei, drei oder noch mehr
Festplatten /einschalten/ muß. Mein Ziel ist aber, soviel Festplatten
wie möglich so lange wie möglich /ausgeschaltet/ zu haben - weil die
einen Haufen Strom fressen.

|ACL gehen damit zwar zur Zeit nicht, aber kann Bacula ACL?

Ei sieh an, FreeBSD kann ACLs! Nett. Hab ich gar nicht mitgekriegt.
Bacula kann :
>UNIX Access Control Lists (ACL) as defined in IEEE Std 1003.1e draft
>17 and "POSIX.1e" (abandoned). This feature is available on UNIX only
>and depends on the ACL library.

|Ich behaupte ja nicht, dass es nicht reparabel ist, aber die
|Vergangenheit hat da eine Gewisse Lernresistenz gezeigt.

Ja nu. Gewisse Mängel an professioneller Programmierkunst gehen
nicht notwendig mit erhöhter Sozialkompetenz einher. Das Vorhandesein
von ersterer aber oft auch nicht...

|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.

Eha, interessant. Ganz ohne dass ich diese Diskussionen irgendwie
mitgekriegt hätte: was ich mir angeschaut hab, stellt sich so dar,
dass der FreeBSD Tapedriver (bis einschließlich Release 5.5) nicht
imstande ist, bei einem fast-forward die Anzahl Files richtig
mitzuzählen. Ich hatte schon geplant, das irgendwann mal zu fixen,
aber offensichtlich funktioniert es in Release 6.3

Natürlich kann man dann drüber streiten, ob eine Applikation sich
auf dieses Feature stützen sollte oder nicht. Im Übrigen wird durch
das Fehlen dieser Funktion das Schreiben nicht weniger zuverlässig,
sondern nur das Positionieren recht langsam. (Korrekte Konfig
vorausgesetzt)

|> |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.

Er will aber keinen Coredump, sondern:

>[Is Bacula Stable? ] Yes, it is remarkably stable, [...]
>There are a number of reasons for this stability.
>[...]
>3. Any signal (segmentation fault, ...) generates a traceback that is
> emailed to the developer. This permits quick resolution of bugs even
> if they only show up rarely in a production system.

Ich find das auch total überzogen und ziemlich schräg - aber vielleicht
ist ja die Userbase so dämlich dass sie gar nicht wissen was ein core
ist?

Und ganz abgesehen davon: wo schreibt denn ein als root laufender
Daemon seinen core hin? So ganz so einfach wie Du es darstellst ist
das halt auch nicht.

|> 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.

Vergiß es. Du musst nicht immer recht haben, und auch FreeBSD ist
nicht immer bugfree. ;)

Unabhängig davon würde ich stark vermuten, dass du nur durch Zufall die
|Symptome beseitigt hast, aber nicht den Fehler.

Der /Fehler/ war die Netzwerkkarte. Netzwerkkarte raus, Problem gelöst.
Ich sage ja nur, dass die art und weise wie der Fehler behandelt
wird, sich durch die Debugoption geändert hat.

|Was ist denn das für einer Karte?

Meine "legacy infrastructure". Baujahr 1991. :)

-- PMc

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Sun 13 Apr 2008 - 00:13:38 CEST