On Windows, the NT Service Controller does all the dirty job. And it's
pretty easy to write a service in Python that can run any application.
The simplest Python service is shorter than 30 lines I think.
Dealing with a service on Windows usually involves:
- Registering/Unregistering the service
- Setting service options
- Startup type (automatic/manual/disabled)
- Username (can be local machine or Active Directory,
if the machine is on a domain)
- Dependencies (a service can depend on other services)
- Failure mode
- There are 3 tries by default, you can customize
what happens on each try
- Ignore
- Restart the Service
- Run a program
- Restart the computer
The service, after being registered can be managed with standard tools
present on the system:
C:\src>net stop bthserv
O serviço de Bluetooth Support Service está sendo finalizado .
O serviço de Bluetooth Support Service foi finalizado com êxito.
C:\src>net start bthserv
O serviço de Bluetooth Support Service está sendo iniciado.
O serviço de Bluetooth Support Service foi iniciado com êxito.
You can also use command-line tools to query the service status:
C:\src>sc \\pena queryex bthserv
SERVICE_NAME: bthserv
TYPE : 20 WIN32_SHARE_PROCESS
STATE : 4 RUNNING
(STOPPABLE,NOT_PAUSABLE,ACCEPTS_SHUTDOWN)
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0
PID : 1372
FLAGS :
C:\src>sc \\pena queryex xmlprov
SERVICE_NAME: xmlprov
TYPE : 20 WIN32_SHARE_PROCESS
STATE : 1 STOPPED
(NOT_STOPPABLE,NOT_PAUSABLE,IGNORES_SHUTDOWN)
WIN32_EXIT_CODE : 1077 (0x435)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0
PID : 0
FLAGS :
And that's just the tip of the iceberg. You can manage services on
other machines for example, still from the command line. You can query
service status with WMI, and you can interact with services from .NET.
I would say that, thus, a service manager like 'zdaemon' it's not
actually that useful on Windows *unless* it implements a Windows
Service. In fact, I could see it being used as both a 'standalone
service manager' and as a simple service with the NT Service
Controller with little overlap, though I would highly discourage the
former.
There's some stuff from zdaemon that would be useful though, and do
not work on Windows today due to some over-unixism in zdaemon, like an
interactive prompt and script runner as 'zopectl debug' and 'zopectl
run', I'm sure those two don't need to know about 'fork' or signals.
What I'm really interested in is in how the service would communicate
with the program being controlled. This is the painful part, and where
I think we need to work together to make sure it works on Windows and
on *nix platforms. You can surely count on me to discuss that part.
As I mentioned on another thread, Zope uses 'signals' on *nix, and
'named events' on Windows, by means of the 'Signals' package in Zope.
We could possibly re-use that.
--
Sidnei da Silva
Enfold Systems http://enfoldsystems.com
Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214
_______________________________________________
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
