On Fri, Jul 9, 2010 at 5:23 PM, Tim Chase <python.l...@tim.thechases.com>wrote:
> On 07/09/2010 06:32 PM, Roy Smith wrote:
>
>> i have been asked to guarantee that a proposed Python application will
>>> run continuously under MS Windows for two months time. And i am looking
>>> to know what i don't know.
>>>
>>
>> Heh. The OS won't stay up that long.
>>
>
> While I'm not sure how much of Roy's comment was "hah, hah, just serious",
> this has been my biggest issue with long-running Python processes on Win32
> -- either power outages the UPS can't handle, or (more frequently) the
> updates (whether Microsoft-initiated or by other vendors' update tools)
> require a reboot for every ${EXPLETIVE}ing thing. The similar long-running
> Python processes I have on my Linux boxes have about 0.1% of the
> reboots/restarts for non-electrical reasons (just kernel and Python
> updates).
>
> As long as you're not storing an ever-increasing quantity of data in memory
> (write it out to disk storage and you should be fine), I've not had problems
> with Python-processes running for months. If you want belt+suspenders with
> that, you can take others' recommendations for monitoring processes and
> process separation of data-gathering vs. front-end GUI/web interface.
>
> -tkc
1) Separate the crucial parts from the "need it someday" parts, as
previously suggested. Perhaps run the crucial parts as a system service or
daemon.
2) Use pylint, or at least PyChecker. pylint spills over into stylistic
stuff in places, but it's very valuable in writing bullet proof Python, and
its various warnings can all be turned off if necessary. I've not tried
PyChecker.
3) Test, test, test. Unit test, Component test, System test. Consider
hiring a Q/A person, even if only temporarily - if someone other than the
main developer performs/writes the tests, they'll probably be more merciless
to the code, and hence find more bugs before they become an issue.
4) Seriously: Think about whether you're on the right operating system.
5) Write a list of things that're beyond your control (Power Outages, OS
crashes if they won't let you switch, crucial/unintended system patch,
earthquake, fire, etc) and get your management to sign off on them as not
your fault, with mitigations and contingencies where practical. You might
want to include "...including but not limited to..." at the top of your list
if you can.
6) Put the machine in a controlled machine room, and only access it over RDP
or ssh. Don't put it near the KVM :)
--
http://mail.python.org/mailman/listinfo/python-list
