xinetd hält den Prozess geöffnet, wenn der Client die Verbindung trennt

2431
Sirex

Ich habe diese Frage schon mehr oder weniger über stackoverflow gestellt und glaubte, dass sie gelöst wurde (daher die Antwort akzeptiert), aber es stellte sich heraus, dass sie nicht gelöst wurde. :-(

In einfachen Worten, ich habe ein Python-Skript geschrieben, das Text ständig in stdout ausgibt, das ist alles, was er 24/7 tut. Ich habe es mit dieser Xinetd-Datei verbunden

Dienst Myservice { Instanzen = 1 port = 887 socket_type = stream type = UNLISTED warten = nein Benutzer = Niemand server = /usr/local/bin/myscript.py only_from = 127.0.0.1 192.168.1.2 disable = nein max_load = 5,0 schön = 5 per_source = 1 }

Dies funktioniert auch insofern gut, als wenn ein Client eine Verbindung herstellt, dass auf seiner Konsole Text ausgegeben wird. Das Problem ist, wenn der Client die Verbindung trennt, der gestartete Prozess geöffnet bleibt und den Port blockiert. Es ist nur ein Client zulässig (Instanzen = 1). Dies kann jedoch auftreten, wenn der Client während der Verbindung neu gestartet wird.

Früher dachte ich, dass dies daran lag, dass das Python-Skript Kill-Signale ignorierte (was es war), aber mit diesem Fix wurde dasselbe Verhalten beobachtet. Um zu klären, wird kill -1 usw. vom Python-Skript gerne beobachtet.

Ich gehe davon aus, dass dies ein Problem mit Xinetd ist und ziemlich einfach zu beheben ist?

0

2 Antworten auf die Frage

1
grawity

Beenden Sie den Serverprozess, wenn eine Verbindung getrennt wird.

AddedWenn das Betriebssystem des Servers erkennt, dass die TCP-Verbindung geschlossen wurde, schlägt das Lesen von und das Schreiben von stdout/ stderrfehl mit:

IOError: [Errno 104] Connection reset by peer

Stellen Sie daher sicher, dass Ihr Code keine Ausnahmen ignoriert, wenn sie auftreten.

Diese (und jede andere Methode) funktioniert jedoch nur, wenn der Server die Unterbrechung kennt . Clean-Neustarts schließen in der Regel alle TCP-Verbindungen, das "Ziehen des Steckers" jedoch nicht.

Ist das aus solider Erfahrung? - weil, soweit ich das beurteilen kann, aus dem Python-Skript keine Möglichkeit besteht (vielleicht gibt es da)? - es spuckt die Ausgabe ständig aus, ähnlich wie beim Bash-Befehl "yes". Sirex vor 13 Jahren 0
@Sirex: `sys.stdin` ist an den TCP-Socket gebunden, und wenn der Socket geschlossen ist, schlägt` sys.stdin.write` fehl. Gleiches gilt für jede Sprache: Sie können nicht in einen geschlossenen Socket schreiben. grawity vor 13 Jahren 0
ok, ich lass diese Frage offen, ich gehe für zwei Wochen weg, aber ich werde es testen, wenn ich zurück bin. Ich bin mir nicht sicher, ob die TCP-Verbindung vom Client sauber geschlossen wird, aber ich möchte einen Blick darauf werfen. in dem oben genannten meinst du sys.stdout und sys.stdout.write, sicher? Sirex vor 13 Jahren 0
@Sirex: Ich meinte eigentlich sowohl "sys.stdin" als auch "sys.stdout". (Ja, es hätte entweder stdin.read () oder stdout.write () sein sollen.) grawity vor 13 Jahren 0
-1
Janne Pikkarainen

Hast du versucht zu setzen wait = yes?

Laut Dokumentation ist das so

wait — Defines whether the service is single-threaded (yes) or multi-threaded (no).
schien anfangs nicht zu helfen, aber ich werde weiter testen. Sirex vor 13 Jahren 0

Verwandte Probleme