[Allegro] avanti unter xinetd [Lang]

[Bernhard Eversberg]

Am 06.07.2011 18:45, schrieb Thomas Berger:
> Bei modernen Kerneln faellt bereits auf, dass "top" zwar in der
> Zusammenfassungszeile mehr als 99% "idle" anzeigt, der avanti-
> Prozess aber 8-10% Verbrauch einer virtuellen CPU hat (und nicht 0.05%).
> Evtl. sind das natuerlich 10% der extrem heruntergeregelten CPU,
> alle anderen Dienste ausser Avanti bleiben aber unterhalb der
> Wahrnehmungsschwelle.
Womöglich besagen die 10% aber wirklich kaum was, denn das
Messen von verbrauchten CPU-Leistungen eines Prozesses ist
ja wohl keine simple Sache. Ich denke, auf die 99% "idle"
ist dann schon eher Verlaß.

> Festzuhalten bleibt also erst einmal, dass die sleep- oder usleep-Loesungen
> eine ueblere Kruecke sind, als sowieso schon klar war.
Wir sind ja offen für Verbesserungsvorschläge, und das Programm
avanti ist offen für eigenmächtige Verbesserungen Ihrerseits.

> ---
>
> Ich wollte daher die aelteren Avanti (die ich eigentlich nie benoetige,
> nur installiert vorhalte) ueber xinetd aufstarten, d.h. sie sind
> gar nicht aktiv, weil xinetd das listen() auf dem Socket leistet und
> die Prozesse nur bei Bedarf startet.
>
> Leider ist es da so, dass sich avanti dann ueber die nicht auffindbare
> Konfigurationsdatei beschwert: Arbeitsverzeichnis ist durch xinetd
> auf "/" gestellt (avanti macht dann "//" draus, aber egal), vor
> allem aber kann man sich nicht darauf verlassen, dass argv[0] den
> Pfad zum Executable enthaelt, das ist eine Verabredung der Shell
> mit dem Rest der Welt, xinetd startet avanti aber ohne Zuhilfenahme
> einer Shell (gut). Anscheinend gibt es ueberhaupt keinen portablen
> Weg, ~den~ Pfad des aktuell laufenden Executables zu bestimmen,
> es scheint auch nicht unbedingt eine wohldefinierte Fragestellung...
Das kapiere ich nun gar nicht. Wer denkt sich denn sowas aus,
ein Prozeß, bei dem man gar nicht weiß, wo er denn läuft.
Und ein environment kann man ihm auch nicht mitgeben, mit
einer geeigneten PATH-Variablen, damit er Programme und
Dateien findet?

> Vermutlich ist das auch der Grund fuer gewisse Schwierigkeiten,
> avanti ueber init-Skripte, die den jeweiligen Unix-Distributionen
> nachempfunden sind, glatter in Systeme einzupassen: Je elaborierter
> die Mechanismen,
Das ist doch das Problem, daß man sich auf "elaborierte
Mechanismen" überhaupt erst einläßt. Das ufert doch
zuverlässig aus ("Falle der Komplexität" hat das mal einer
genannt). Lassen Sie da lieber die Finger von.

> Fuer den Produktivbetrieb der Datenbanken ist die Ansteuerung ueber
> xinetd gewiss nicht optimal
Zumal inetd und xinetd nur für relativ selten benötigte
Prozesse wegen des Overheads wirklich empfohlen werden.
Ich verstehe daher gar nicht, warum Sie diesen Weg eigentlich
einschlagen wollen, statt avanti in den fraglichen Punkten zu
modifizieren oder uns Modifikationen vorzuschlagen.

B.Eversberg