[Allegro] Avanti und Acon 2. Versuch

[Bernhard Eversberg]

Am 07.07.2011 15:05, schrieb Thomas Berger:
> Ich habe avanti nun schon wirklich oft installiert, und die
> letzten Tage habe ich eigentlich nichts anderes getan. Und
> diesmal war meine Rettung, dass ich die Quellen vorliegen hatte
> und noch ein paar printf's einfuegen konnte.
Gut, aber was kam dabei raus?

>
> Wer sieht anhand dieser Protokollmeldung, ob acon gestartet
> wurde, ob acon seine Initialisierung ueberlebt hat (inklusive
> finden einer conf-Datei), ob die Datenbank gefunden wurde?
>
> Mein Verdacht ist, dass acon gestartet wurde und dann einen
> coredump produziert hat, ...
Das könnte Herr Schieke mal verifizieren.

> Anderswo? Es wird definitiv nur auf dem Verzeichnis gesucht,
> wo avanti liegt, wenn sie dort nicht gefunden wird, auf ../etc.
> Schlägt beides fehl, wird beides nochmal versucht, und zwar
> mit .conf statt .con
> Das kann bei einer Migration, wenn eine Standard-avanti.con
> eine vorhandene avanti.conf ueberlagert, schon zu
> Ueberraschungen fuehren.
Ja, aber solche Situationen werden allmählich seltener.

>
>>
>> - uifsger muss im Verzeichnis von avanti liegen, weder muss
>>     es wie (sehr viel) frueher uifSger heissen noch wird es
>>     im etc-Verzeichnis akzeptiert.
>> Sind Sie sicher bzgl. des letzteren?
> Ich meine mich zu erinnern, dass es hierzu letzten Sommer
> Diskussionen gab.
Ich habe gerade nochmal getestet. Was ich schrieb, stimmt.

>
> uifsger hat m.W. nichts mehr mit avanti zu tun, sondern nur
> noch mit acon, insofern ist ../etc da untypisch. Andererseits
> kennt acon ja ../etc immer noch, weil es bei Bedarf die
> avanti.conf konsultiert...
Ja, aber nur, wenn keine .con vorhanden ist.
> Es kann z.B. sein, dass man avanti aktualisiert, aber kein
> aktuelleres avanti-cl findet: Pardauz. Oder bei einer
> Aktualisierung etwas fehlschlaegt und man ohne es zu wissen mit
> einem alten avanti arbeitet, obwohl inzwischen nur acon dort
> liegt: Es geht nicht um "sinnvoll", sondern um moegliche
> Fehlerquellen.
Richtig, aber wir empfehlen natürlich immer, erst mal die
aktuellen Versionen zu nehmen, weil wir ja auch nur daran
Verbesserungen vornehmen können. Und die aktuellen Versionen
zu finden, das wollen wir ja gerne weiter verbessern...
Alle Eventualitäten mit evtl. von früher vorhandenen Versionen
und Varianten können wir unmöglich abfangen. Empfehlung:
../etc endlich mal löschen, oder, wer Angst hat, umbenennen,
um zu sehen, was passiert.

> Die erschoepfende Auflistung finden Sie in den Quellen von acon:
> Wird dort jeder Call auf moegliche Fehlerzustaende im Ergebnis
> abgetestet und in jedem Fall ein Protokolleintrag erzeugt, der
> moeglichst sogar den erhaltenen Fehlercode angibt?
Jeder Call? Das wäre ja wohl overkill.

> Bezueglich avanti habe ich nur gesehen, dass dort errno.h (fuer Linux)
> nicht eingebunden wird, d.h. es gibt keine einzige Stelle, wo
> ernsthaft versucht wird, dem Anwender Fehlerzustaende zu kommunizieren!
>
>
Eine grobe Übertreibung. errno.h ist für Win32 eingebunden,
für Linux nicht, das stimmt. Aber es gibt ja eine aufwendige
Methodik für die Log-Datei, die man selber einstellen kann,
und es gibt noch diverse andere, direkte Fehlermeldungen bei
Fehlschlägen, die bekanntermaßen praktisch vorkommen.
Das hat mit errno.h nichts zu tun, belegt aber, daß wir nun
wirklich etwas tun, um Fehlerzustände zu kommunizieren.
Es geht nun darum, noch weitere Zustände klar zu identifizieren,
die praktisch vorkommen und bisher nicht abgefangen werden.
In acon, das erheblich komplexere Programm, ist übrigens errno.h 
eingebunden.
(In Kürze wird es freigegeben)
B.E.