Re: Suche Debughilfe: child never returns from fork?

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

|> Und, ich hab mal das close() durch ein open() ersetzt - das taucht
|> auch nicht auf - also entweder bleibt er auch im Eingang von dem
|> open() hängen, oder er kommt doch schon aus dem fork() nicht raus.
|
|Also, dass der schon beim fork selber Ärger macht ist schon ziemlich
|ungewöhnlich.
|Ist das Programm gegen eine Thread-Library gelinked?
|Obwohl selbst dabei sollte der fork eigentlich durchlaufen.

Ich weiss es nicht. Ich sehe mit ktrace genau nichts. Ich sehe
mit Top eine Menge IVCSWs. Und ich denke, Dein Hinweis auf den
DDB ist noch die vielversprechendste Spur von allen.
Interessant finde ich es deswegen, weil es eindeutig erst mit
Release 6 gekommen ist. Das Argument, dass da schlechter Stil
programmiert wurde, akzeptiere ich - dennoch finde ich es
interessant zu wissen was sich bei Release 6 anders verhält als
bei 5.

|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.
Auch mag es so sein, dass es uns Menschen gar nicht möglich
ist, _alle_ Begehrlichkeiten zu verwirklichen. Will meinen, eine
gute Idee haben und diese Idee in einem Code zu materialisieren
der überhaupt mal läuft (und auch noch verständlich ist), das
ist schon eine Leistung. Das dann in einer portablen Weise zu
tun wäre vielleicht eine weitere Leistung, die einen anderen
Genius erfordert...

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

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

Und die andere Seite sind eben die Funktionen die es bietet.
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.
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. ;-))

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

|Kaskadierte Sighandler sind nicht ohne.

Das hat man berücksichtigt und alle Sighandler mit sigfillset()
versorgt. :-/

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

|> (*) 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. :(
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.
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).

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

Gruessli
PMc

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