python xinetd client disconnection handling

This may or may not being a coding issue. It may also be an xinetd deamon issue, i do not know.

I have a python script which is triggered from a linux server running xinetd. Xinetd has been setup to only allow one instance as I only want one machine to be able to connect to the service, which is therefore also limited by IP.

Currently when the client connects to xinetd the service works correctly and the script begins sending its output to the client machine. However, when the client disconnects (i.e: due to reboot), the process is still alive on the server, and this blocks the ability for the client to connect once its finished rebooting or so on.

Q: How can i detect in python that the client has disconnected. Perhaps i can test if stdout is no longer being read from by the client (and then exit the script), or is there a much eaiser way in xinetd to have the child process be killed when the client disconnects ?

(I'm using python 2.4.3 on RHEL5 linux - solutions for 2.4 are needed, but 3.1 solutions would be useful to know also.)

Thanks this worked a treat. On further inspection i'd actually caught all exceptions somewhere else in the code and so sighup wasnt being passed on.

Sirex 2010-07-06 10:39:12

Sorry to dig this up, but i've only just got round to putting this live. Oddly, this didnt actually work as i thought it had. The process dies when sent signal one (kill -1 <pid>) which means according to this answer it should die when xinetd is disconnected, but it dosent. The original problem was that the child python process started by xinetd when a client connects, stays alive even when the client has disconnected. That issue is still there :-(My python process just prints output to stdout (and due to xinetd, to a client's screen) - do i need to alter xinet's config prehaps ?

Sirex 2010-08-26 08:20:35

ansaurus

tags:

views:

answers:

python xinetd client disconnection handling

related questions