# Stopping a program properly :: Telnet -\> ConnectPort **URL:** \ **Category:** Python\ **Created:** [April 15, 2011, 5:48am UTC](https://forums.digi.com/t/stopping-a-program-properly-telnet-connectport/2926 "2011-04-15T05:48:59Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![adriftatsea](https://avatars.discourse-cdn.com/v4/letter/a/958977/32.png) [@adriftatsea](https://forums.digi.com/u/adriftatsea)\ **Post date:** [April 15, 2011, 5:48am UTC](https://forums.digi.com/t/stopping-a-program-properly-telnet-connectport/2926/1 "2011-04-15T05:48:59Z")
In short, without being able to ‘Ctrl+C’ when telnet’ed into my ConnectPort X2 - how am I to stop a wayward Python script? In more detail: I have an Arduino (programmed to print out the value of a sensor once every 15 seconds) attached to an Xbee connected to a ConnectPort X2. To view the stream of data, I used the ‘Non Blocking I/O’ script ([found here](http://www.digi.com/wiki/developer/index.php/Zigbee_Extensions_to_the_Python_socket_API#Send_.E2.80.9CHello.2C_World.21.E2.80.9D)) and modified it to print to screen the payload variable. And if I telnet into my ConnectPort and run ‘python foo.py’ - it works. However there is no command sequence to stop the program. Doing a ‘who’ and trying to ‘kill’ or ‘close’ the appropriate connection doesn’t work… Sorry for being dense. ---
**Author:** ![lynnl](https://avatars.discourse-cdn.com/v4/letter/l/22d042/32.png) [@lynnl](https://forums.digi.com/u/lynnl)\ **Post date:** [April 15, 2011, 2:27pm UTC](https://forums.digi.com/t/stopping-a-program-properly-telnet-connectport/2926/2 "2011-04-15T14:27:00Z")
adriftatsea - hope you have some sun block 🙂 There is really no 100% reliable way to kill a broken script. Many tools open a 2nd server socket (a bind on another port) and use any client attempt to connect to it as a kill signal. So you’d hand-code your own kill & clean-up routines as part of the script. But since the X2 has limited resources and runs a single Python ‘environment’ shared by all scripts, there is no 100% promised way to free up all Python resources locked by the dead/dying script. For example, if the dying script leaves the socket to the XBee ‘used/bound’, then trying to rerun your script will fail because you can no longer talk to the XBee of the X2. Rebooting the X2 is the only 100% predictable ‘kill’ method. You may be interested in the new X2D - example part number for the ZigBee version is X2-Z11-EM-A (old P/N was X2-Z11-E-A). This X2 has 16Mb RAM/8MB FLASH and an ARM9 processor, whereas the older X2 had only 8MB RAM/4MB FLASH and a slower ARM7 processor. ---
**Author:** ![adriftatsea](https://avatars.discourse-cdn.com/v4/letter/a/958977/32.png) [@adriftatsea](https://forums.digi.com/u/adriftatsea)\ **Post date:** [April 15, 2011, 11:44pm UTC](https://forums.digi.com/t/stopping-a-program-properly-telnet-connectport/2926/3 "2011-04-15T23:44:49Z")
Thanks Lynn, that was most helpful and made perfect sense. I’ll start working/reading on building a kill routine within my python script. So even with the larger X2D, I imagine having multiple interpreters running would be too much to expect in 16MB? ---
**Author:** ![lynnl](https://avatars.discourse-cdn.com/v4/letter/l/22d042/32.png) [@lynnl](https://forums.digi.com/u/lynnl)\ **Post date:** [April 18, 2011, 11:40am UTC](https://forums.digi.com/t/stopping-a-program-properly-telnet-connectport/2926/4 "2011-04-18T11:40:57Z")
It is more of an operating system thing than pure RAM. Think of how complex a set of ‘fences/corrals’ an OS like Windows or Linux has to build around everything from a serial port to RAM to file-handles in order to correctly clean up an arbitrarily large collection of resources after a crashed thread. Most small embedded devices work in stead-state and never see a crashed thread. So the OS doesn’t waste the space & performance penalty used only during development. One thing I do is work as much as I can on a PC - do unit tests of modules designs independently from the rest of the code.