medusa as win32 service

[Robin Becker]

I wonder if this is the right way to write a medusa(asyncore) server
with the win32all framework. Other example services seem to create an
event to pass the stop signal from SvcStop into a separate termination
method, but I'm unsure how that would mix with the polling loop.

This simple framework seems to start and stop OK, but I wonder if I'm
missing some obvious race or something.



import win32serviceutil, win32service,
class MeducaService(win32serviceutil.ServiceFramework):
_svc_name_ = "MedusaService"
_svc_display_name_ = "Medusa Service"
def __init__(self, args):
win32serviceutil.ServiceFramework.__init__(self, args)

def SvcStop(self):
self.ReportServiceStatus(win32service.SERVICE_STOP_PENDING)
print "Received Quit from Win32"
socket_map = asyncore.socket_map
while socket_map:
k, v = socket_map.popitem()
try:
print "Shutting down",k,v
v.close()
except:
pass
del k, v

def SvcDoRun(self):
start_medusa()

 

[Pekka Niiranen]

Hi,

Before I start the trial & error -cycle,
has anybody tried to start Bash -shell
script in Cygwin environment
from Python running in W2K?

True, Cygwin has Python package available, but I would like to
use true W2K version of Python. This would be the first
step of gradual conversion of all the shell scripts in Cygwin
to true W2K Python scripts: I would initially have WxPython Menu
in W2K from which I start Cygwin scripts.

-pekka-

 

[Mark Hammond]

I wonder if this is the right way to write a medusa(asyncore) server
with the win32all framework. Other example services seem to create an
event to pass the stop signal from SvcStop into a separate termination
method, but I'm unsure how that would mix with the polling loop.

This simple framework seems to start and stop OK, but I wonder if I'm
missing some obvious race or something.

SvcStop will be called on a different thread. I don't know enough about
socket semantics to know if this is an issue.

When I've tried to play with async based services, IIRC there were a few
problems if a connection existed at shutdown time. If "close" could
ever block, then Windows would get quite upset. If a "close()" ever
fails, then I guess there is a risk that the main loop will not
terminate, again making Windows upset. But as above, I don't know
enough about the framework to comment on the risks here.

So really, the issues are all Python related - the win32 interactions
appear OK, assuming close could never block.

For the SpamBayes project, our framework needed a "clean shutdown" to
save our databases etc, so we ended up using urlopen to connect to a
special "shutdown" URL. I didn't write that part, so I don't understand
if there was a better option.

Hope this helps a little

Mark.

 

[Giles Brown]

I wonder if this is the right way to write a medusa(asyncore) server
with the win32all framework. Other example services seem to create an
event to pass the stop signal from SvcStop into a separate termination
method, but I'm unsure how that would mix with the polling loop.

This simple framework seems to start and stop OK, but I wonder if I'm
missing some obvious race or something.

I think the cleanest design for this is to use the
medusa.threading.select_trigger function to send an asyncore.ExitNow
exception into the main select loop. The only problem with this is
that the current medusa.threading.select_trigger (in the sourceforge
medusa version) catches (and does not re-raise) this exception. I've
modified our code so that it does not catch it and this seems to work
very well (we have a web server using medusa that runs as a service).

Regards,
Giles Brown

 

[Robin Becker]

SvcStop will be called on a different thread. I don't know enough about
socket semantics to know if this is an issue.

When I've tried to play with async based services, IIRC there were a few
problems if a connection existed at shutdown time. If "close" could
ever block, then Windows would get quite upset. If a "close()" ever
fails, then I guess there is a risk that the main loop will not
terminate, again making Windows upset. But as above, I don't know
enough about the framework to comment on the risks here.

So really, the issues are all Python related - the win32 interactions
appear OK, assuming close could never block.

For the SpamBayes project, our framework needed a "clean shutdown" to
save our databases etc, so we ended up using urlopen to connect to a
special "shutdown" URL. I didn't write that part, so I don't understand
if there was a better option.

Hope this helps a little

it does indeed as I'm then into ensuring that the close methods are
reasonable. So I guess the problem reduces to whether the simple medusa
services ftp/http are cleanly terminatable.

As a matter of interest how does one get rid of LEGACY services? Whilst
getting the above going I seem to have created a LEGACY_MEDUSASERVICE in
the registry. All attempts at deletion fail.

 

[Robin Becker]

I think the cleanest design for this is to use the
medusa.threading.select_trigger function to send an asyncore.ExitNow
exception into the main select loop. The only problem with this is
that the current medusa.threading.select_trigger (in the sourceforge
medusa version) catches (and does not re-raise) this exception. I've
modified our code so that it does not catch it and this seems to work
very well (we have a web server using medusa that runs as a service).

Regards,
Giles Brown

well it is an opensource project, so perhaps you could submit patches.
I'm not sure how much work A Kuchling would/could devote to it. I also
have made some relatively trivial changes to the status extension, but
they don't affect very much.

 

[Jason Tishler]

Pekka,

Before I start the trial & error -cycle, has anybody tried to start
Bash -shell script in Cygwin environment from Python running in W2K?

Something like the following should meet your needs:

Python ... [MSC 32 bit (Intel)] on win32 foo
0

Jason

 

[David Bear]

I have used w32python interactively from a cygwin bash. its okay.
but I think I remember that the python environment (syspath?) was not
set properly. so, this would be something to check in your cygwin
bash rc file..

--
David Bear
phone: 480-965-8257
fax: 480-965-9189
College of Public Programs/ASU
Wilson Hall 232
Tempe, AZ 85287-0803
"Beware the IP portfolio, everyone will be suspect of trespassing"