[Allegro] Avanti und Acon 2. Versuch

Thomas Berger ThB at Gymel.com
Do Jul 7 15:05:02 CEST 2011


Lieber Herr Eversberg,

>> [Zu Ihrer Mail von vorgestern: Die Stelle, an der Sie da haengen,
>> ist diejenige, wo es am haeufigsten schiefgeht, aus der
>> groessten Vielzahl von Gruenden und mit den spaerlichsten
>> Fehlermeldungen.
> Welche kommen nicht, obwohl sie kommen könnten oder sollten?
> Welche sind zu spärlich?
> Konkret bitte, solche Pauschalangaben bieten keinen Ansatzpunkt
> für verbessernde Eingriffe.

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.

Die Erfahrung ist einfach, dass es ganz typisch ist, dass avanti
laeuft und trotzdem nichts funktioniert, Herr Schieke hat das
ja vorgestern dokumentiert:

[2011-05-25 18:39:54]     (IO) <conn 0> socket -> stdin (61 bytes) <at
avanti.c, line 584>
[2011-05-25 18:39:54]   (DATA) Transcript of transferred data:
--- begin ---
AVANTI:EOR


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, es sich also um einen "drastischen"
Fehler handelt, der typischerweise mit fehlenden / falsch
benannten / sonstwie nicht gefundenen Dateien zu tun hat...



>> - Wird Ihre avanti.con[f] genommen, oder agiert avanti mit
>>    irgendwelchen Defaults bzw. einer von anderswo eingefangenen
>>    Konfigurationsdatei?
> 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.


> Anderswo nicht, und irgendwelche Defaults gibt es nicht.
>> - 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 muss allerdings einraeumen, dass ich inzwischen den
Versuch weitgehend aufgegeben habe, das etc-Verzeichnis als
Arbeitsverzeichnis zu nehmen, es koennte sein, dass es
in "." und im Programmverzeichnis (aus dem Aufruf abgeleitet)
gesucht wird.

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



>> - alte Avanti's beauftragten avanti-cl, neuere das Binary acon.
>>    Mix alt/neu oder neu/alt geht im Prinzip, aber ansehen kann
>>    man einem Avanti-Binary nicht unbedingt, was er erwartet.
> Und warum sollte man ein altes avanti mit einem neuen acon einsetzen?
> Das kann nicht klappen, weil das alte avanti nicht acon sucht,
> sondern avanti-cl, aber auch sonst wäre es wenig sinnvoll.

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.


>> - Liegt die Datenbank da, wo acon sie sucht (es werden zwar
>>    Parameter- und auch andere Probleme protokolliert, m.E.
>>    aber nicht alle denkbaren) bzw. ist sie dort auch zugaenglich
>>    (Rechte).
> Nicht alle denkbaren? Bitte um eine erschöpfende Auflistung,
> damit wir tätig werden können.

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?

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!

viele Gruesse
Thomas Berger



Mehr Informationen über die Mailingliste Allegro