Windows service in production?

[Adam Jorgensen]

Yeah, we run our Python App as a service under Windows.

You can look at the open-souce part of our product using
http://trac.sjsoft.com/browser
If you look into the code you should be able to find some stuff to do with
services.

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):
>            try:
>                self._fp.write(data)
>            except:
>                pass
>
>        # 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/
>
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20110819/3aac6ab4/attachment-0001.html>