Re: Suche Debughilfe: child never returns from fork?

From: Oliver Fromme <olli(at)lurza.secnetix.de>
Date: Sun, 13 Apr 2008 14:26:33 +0200 (CEST)

Peter Much wrote:
> Bernd Walter wrote:
> > [...]
> 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.

Ja, dass es ein Timing-Problem in der Software sein muss,
war anhand Deiner Beschreibung ziemlich klar.

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

Leider. Zumindest nicht im üblichen UNIX-Umfeld.

Allerdings kommt es auch immer drauf an, um was für eine
Software es geht. Ich gebe Bernd vollkommen recht, dass
eine Backup-Software eine kritische Sache ist. Wenn die
etwas falsch macht, kann das üble Folgen haben.

Und genau deswegen kann man hier die Redensart mit dem
geschenkten Gaul nicht anwenden. Die Software mag kosten-
los sein, aber was für Kosten hast Du, wenn der Fall
eintritt, dass Du auf ein Restore angewiesen bist und es
nicht funktioniert? Was ist, wenn es in 499 von 500
Fällen funktioniert und Du Pech hast?

Jemand, der eine so kritische Software wie ein Backup-
Programm schreibt und es veröffentlicht, der trägt eine
gewisse Verantwortung und muss es sich gefallen lassen,
dass man ihr »ins Maul schaut«.

Und wenn es der Programmierer nichtmal gebacken kriegt,
eine verkettete Liste korrekt freizugeben oder der
eigenen PID ein Signal zu schicken -- und das sinf ganz
klare Anfängerfehler, die nicht passieren dürfen! --,
dann habe ich in den ganzen Rest der Software auch nicht
besonders viel Vertrauen, und ich werde sie ganz bestimmt
nicht für meine Backups einsetzen. So einfach ist das.

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

Snapshots haben per-se nichts mit Backups zu tun, aber
Du hattest nach einer Art un-delete gefragt, und das
leisten Snapshots sehr wohl und mit minimalem Overhead.

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

Das kannst Du bei ZFS auch.

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

Verstehe ich nicht ganz, gvinum _ist_ eine geom-Klasse.
ZFS soll auch nicht geom ersetzen; beides verhält sich
orthogonal.

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

Es kommt halt immer darauf an, was man haben will.
Alle diese Dinge dienen ja ganz unterschiedlichen Dingen:

 - Ein RAID dient der Redundanz, Verfügbarkeit und Per-
   formance (je nach RAID-Level). Als Backup aber ist
   es vollkommen ungeeignet.

 - Snapshots können als Archivierungsfunktion, für eine
   Art un-delete und ähnliches dienen. Ein Backup stellen
   sie nicht direkt dar, aber man kann sie für Backups
   einsetzen.

 - Ein Backup dient allein der Datensicherung und muss
   daher auf Medien gemacht werden, die nach der Anferti-
   gung des Backups entfernt und separat gelagert werden
   (optische Medien, Bänder, Wechselfestplatten o.ä.).
   Für ein un-delete sind Backups ungeeignet.

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

Das ist ja der Gipfel. Das wusste ich noch gar nicht.
Ich kann nur hoffen, dass das konfigurierbar ist.

Auch das ist wieder ein Punkt, der mein Vertrauen in
die Software nicht stärkt. Im Gegenteil. Da muss man
sich fragen, ob die Entwickler überhaupt mit einem
Debugger umgehen können.

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

Das muss der User auch nicht wissen. Es genügt, wenn die
Entwickler in die Doku schreiben, wass der User im Falle
eines Coredumps machen sollte. Und das ist nun wirklich
nicht schwer. Insbesondere hat dann auch der User die
Kontrolle darüber, was für Daten an die Entwickler gemailt
werden.

> Und ganz abgesehen davon: wo schreibt denn ein als root laufender
> Daemon seinen core hin?

Ich hoffe doch wohl sehr, dass der Backup-Daemon nicht als
root läuft, sondern z.B. als operator.

Und ein Coredump wird per Default in das aktuelle Arbeits-
verzeichnis geschrieben (sofern dort Schreibrecht besteht).
Der Admin kann aber auch alle Coredumps in ein bestimmtes
Verzeichnis schreiben lassen, indem er sysctl kern.corefile
entsprechend setzt.

> So ganz so einfach wie Du es darstellst ist
> das halt auch nicht.

Doch, ist es.

> |> 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 ist mit Sicherheit ein Folgefehler irgendeines anderen
Bugs (z.B. in besagtem NIC-Treiber), aber hat nicht direkt
etwas mit DEBUG=-g zu tun.

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

Ja, sowas nennt sich »Heisenbug«. Das kommt durchaus
häufiger vor, dass ein Bug Symptome hervorruft, die sich
durch die Art des Debuggings ändern.

Es genügt ja schon, dass aufgrund eines Pointer-Fehlers ein
Byte an eine zufällige (falsche) Adresse geschrieben wird.
Ändert man die Debug-Einstellungen, kann sich das Speicher-
Layout des Kernels verändern, und der Amok-laufende Pointer
trifft dann eine ganz andere Stelle im Kernel. Das kann
zu anderen (schlimmeren oder weniger schlimmen) Symptomen
führen. Im worst-case macht es sich gar nicht bemerkbar,
sondern der Kernel rechnet mit einem falschen Wert weiter
und crasht erst sehr viel später an einer ganz anderen
Stelle.

> |Was ist denn das für einer Karte?
>
> Meine "legacy infrastructure". Baujahr 1991. :)

Zeit für ein Upgrade, würde ich sagen. :-)

Gruß
   Olli

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd
"One of the main causes of the fall of the Roman Empire was that,
lacking zero, they had no way to indicate successful termination
of their C programs."
        -- Robert Firth
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 - 14:26:59 CEST

search this site