Stopping a program properly :: Telnet -> ConnectPort

Python
1

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) 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.

2

adriftatsea - hope you have some sun block :slight_smile:

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.

3

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?

4

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.