Windows service in production?
adam.jorgensen.za at gmail.com
Fri Aug 19 01:21:25 EDT 2011
Yeah, we run our Python App as a service under Windows.
You can look at the open-souce part of our product using
If you look into the code you should be able to find some stuff to do with
Specficially, look in trunk/j5/src/j5/OS/WinService.py
On 19 August 2011 07:00, Stephen Hansen <me+list/python at ixokai.io> wrote:
> On 8/15/11 9:32 PM, snorble wrote:
> > Anyone know of a Python application running as a Windows service in
> > production? I'm planning a network monitoring application that runs as
> > a service and reports back to the central server. Sort of a heartbeat
> > type agent to assist with "this server is down, go check on it" type
> > situations.
> > If using Visual Studio and C# is the more reliable way, then I'll go
> > that route. I love Python, but everything I read about Python services
> > seems to have workarounds ahoy for various situations (or maybe that's
> > just Windows services in general?). And there seem to be multiple
> > layers of workarounds, since it takes py2exe (or similar) and there
> > are numerous workarounds required there, depending on which libraries
> > and functionality are being used. Overall, reading about Windows
> > services in Python is not exactly a confidence inspiring experience.
> > If I knew of a reference example of something reliably running in
> > production, I'd feel better than copying and pasting some code from a
> > guy's blog.
> Belatedly: I run a few quite major windows services which are installed
> at various customer sites in production, and we have no issues with it
> being a windows service.
> I basically only ever ran into two problems:
> 1. The lack of a console. Your service flat out /does not have/ a
> console, which is a slightly weird state to be in: writing to sys.stdout
> will fail. A print statement left in can crash things up -- even if in
> third-party code.
> Now, once you realize this is there, its easy to "fix". I end up
> doing something like this very early on in processing:
> class FakeFile:
> def __init__(self, fp):
> self._fp = fp
> def write(self, data):
> # repeat with flush()
> sys.stdout = FakeFile(sys.stdout)
> sys.stderr = FakeFile(sys.stderr)
> That way it'll run from a regular terminal fine and write out fine,
> but if any stray attempts to print are left in, things will pass through
> fine when its running as a service.
> 2. Importing modules with the same names as dlls in system32 can go
> awry. I don't know if this is still there, I last touched this part of
> our code a long, long, long time ago: but my service does some manual
> PATH / PYTHONHOME / PYTHONPATH fiddling to take care of it. Its easy
> to do.
> It worked fine, and was stable and once going, everything worked fine.
> Ultimately, I have since abandoned running things as a real service
> directly, and wrote a "Metaservice" application we use in our company
> instead. It runs as a service, and executes any random series of
> programs beneath it, creating JOB's for each so any subprocesses of they
> launch all get killed together cleanly, and handling dependencies via
> between them through various means, and stuff like that. I just got
> tired of dealing with windows stuff, so. :)
> Stephen Hansen
> ... Also: Ixokai
> ... Mail: me+list/python (AT) ixokai (DOT) io
> ... Blog: http://meh.ixokai.io/
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-list