xinetd maintient le processus ouvert lorsque le client se déconnecte

J'ai déjà posé cette question plus ou moins auparavant sur stackoverflow et je pensais que c'était résolu (donc accepté la réponse) mais il s'avère que cela n'a pas été résolu. :-(

En termes simples, j’ai écrit un script python qui ne fait que restituer du texte constamment sur stdout, c’est tout ce qu’il fait 24h / 24 et 7j / 7. Je l'ai lié à ce fichier xinetd

service myservice
{
    instances = 1
    port = 887
    socket_type = stream
    type = UNLISTED
    wait = no
    user = nobody
    server = /usr/local/bin/myscript.py
    only_from = 127.0.0.1 192.168.1.2
    disable = no
    max_load = 5.0
    nice = 5
    per_source = 1
}

Cela fonctionne bien dans la mesure où lorsqu'un client se connecte, il commence à cracher du texte sur sa console. Le problème est que lorsque le client se déconnecte, le processus lancé reste ouvert, bloquant le port. Un seul client est autorisé (instances = 1), mais cela peut se produire lorsque le client redémarre lorsqu'il est connecté.

Auparavant, je pensais que c'était parce que le script python ignorait les signaux d'arrêt (ce qui était le cas), mais avec cette correction, le même comportement est observé. Pour clarifier, kill -1 etc. est maintenant observé avec bonheur par le script python.

Je suppose que c'est un problème de xinetd et assez simple à résoudre?

linux python xinetd

— Sirex
source

Réponses:

Faites en sorte que le processus serveur se ferme lorsqu'il détecte une déconnexion.

Added Lorsque le système d'exploitation du serveur détecte que la connexion TCP a été fermée, lit et écrit à partir de stdout / stderr échouera avec:

IOError: [Errno 104] Connection reset by peer

Assurez-vous donc que votre code n'ignore pas les exceptions lorsqu'elles se produisent.

Cependant, cela (et toute autre méthode) ne fonctionnera que lorsque le serveur sait à propos de la déconnexion. Les redémarrages en mode nettoyage ferment généralement toutes les connexions TCP, mais pas le "débranchement".

— grawity
source

est-ce une expérience solide? - Parce que pour autant que je sache, il n’ya aucun moyen de le faire à partir du script Python (peut-être qu’il existe)? - il ne fait que cracher sa sortie constamment, semblable à la commande "yes" bash.

— Sirex

@Sirex: sys.stdin est lié au socket TCP, et si le socket est fermé sys.stdin.write va échouer. La même chose s'applique à n'importe quelle langue: vous ne pouvez pas écrire sur un socket fermé.

— grawity

ok, je vais laisser cette question ouverte car je pars pendant 2 semaines, mais je vais tester quand je reviens. Je ne suis pas sûr si la connexion TCP est fermée proprement par le client mais je vais mal jeter un oeil. ci-dessus, vous voulez dire sys.stdout et sys.stdout.write, sûrement?

— Sirex

@Sirex: je voulais dire à la fois sys.stdin et sys.stdout. (Oui, ça aurait dû être soit stdin.read() ou stdout.write().)

— grawity

-1

Avez-vous essayé de définir wait = yes?

Selon la documentation, c'est

wait — Defines whether the service is single-threaded (yes) or multi-threaded (no).

— Janne Pikkarainen
source

n'a pas semblé aider initialement, mais je vais tester plus loin.

— Sirex