2010-07-06 19 views
0

J'ai écrit un script python qui fait des sorts et des trucs pysqlite, mais j'ai remarqué que dans les occasions où j'ai exécuté ce script sur ssh quand que la session ssh est détruite pour une raison quelconque, le script python ne sort pas réellement, à la place il finit comme étant un enfant d'init et reste juste là pour toujours. Je ne peux pas tuer -9 eux ou quoi que ce soit. Ils augmentent également la charge système signalée de 1. Actuellement, j'ai 8 de ces processus la plupart du temps morts, et le serveur a une moyenne de charge de 8.abit. Je suppose que c'est parce qu'il y a une sorte de ressource que ces scripts attendent, mais lsof ne montre rien de réellement ouvert par eux, tous les fichiers de données qu'ils utilisent sont listés comme supprimés etc ... et ils n'utilisent aucun temps de CPU. . Je fais des vérifications de signaux dans le script, en appelant à faire des routines de rafraîchissement sur un HUP, mais rien d'autre, pas de forking ou quoi que ce soit et je ne sais pas pourquoi les scripts ne sont pas juste des shuffling éteint quand je ferme ma session ssh.Scripts Python (curses + pysqlite) suspendus après que le shell parent disparaisse

Merci Chris

+0

Elaborer sur 'ne peut pas tuer -9 eux ou quoi que ce soit'. Voulez-vous dire que vous pouvez réussir une commande 'kill -9' et que le processus persiste ?! – MattH

+0

Oui, ils ne répondent à aucune méthode que je connais pour se débarrasser des processus. Ils ne sont pas non plus des zombies. –

Répondre

1

Eh bien, la raison pour laquelle ils ne sont pas arrêter lorsque votre session ssh se termine parce que HUP est le signal utilisé par un parent pour informer ses enfants qu'ils ARRÊTER. Si vous remplacez le comportement de ce signal, vos processus ne s'arrêteront pas automatiquement lorsque la session SSH sera fermée. Quant à savoir pourquoi vous ne pouvez pas les tuer, cependant, je suis à perte. La seule chose que j'ai vu qui provoque ce comportement est les processus bloqués sur les systèmes de fichiers mal agités (nfs & unionfs étant les deux avec lesquels j'ai rencontré le problème).

+0

Il lit une base de données sqlite sur NFS, donc ça devrait être un angle ... Est-ce qu'il envoie vraiment un hup pour le fermer? pas un signal différent? J'intercepte hup afin de recharger les configurations dans l'outil, comme hupping un processus démon. Évidemment, ils sont correctement fourchus, alors que j'essaie juste de l'obtenir pour fermer sa connexion DB pendant quelques minutes afin que la base de données sqlite puisse être gâchée par d'autres scripts ... Je suppose que je pourrais choisir un autre signal? –

+0

Ouais, HUP est l'abréviation de "Hang UP" et retourne aux anciens jours de la ligne série où il a été utilisé pour tuer les processus en arrière-plan lorsque l'utilisateur "raccroché" (fermé le terminal). Les démons modernes l'utilisent exactement comme vous le suggérez, mais c'est parce qu'ils ne sont pas destinés à être contrôlés via un terminal et un shell. Pour le débogage, je suggère SIGUSR1 alors peut-être revenir en arrière quand vous frappez la production. Pour plus d'informations: http://en.wikipedia.org/wiki/SIGHUP – Rakis