win32utils devel - Feb 2004 - Hooks for win32-service

Just trying to come up with hooks for win32-service.  It looks like
Perl''s Win32::Daemon defines these:

start....................The service is starting.
pause....................The service is entering a paused state.
continue.................The service is resuming from a paused state.
stop.....................The service is stopping
running..................The service is running
interrogate..............The service is being queried for information.
shutdown.................The system is being shut down.
param_change.............There has been a parameter change to the
system.
net_bind_add.............A new network binding has been made.
net_bind_remove..........A network binding has been removed.
net_bind_enable..........A network binding has been enabled.
net_bind_disable.........A network binding has been disabled.
device_event.............A device has generated some event.
hardware_profile_change..A change has been made to the system''s
hardware
profile.
power_event..............A power event has occured (eg change to battery
power).
session_change...........There has been a change in session.
user_defined.............A user defined event has been sent to the
service.

We can change the names as we see fit obviously.  Should we also add
hooks for pause_pending, start_pending, and stop_pending?

I''m primarily concerned with the start, stop, continue, running and
shutdown hooks.  At least that''s where I''d like to start
initially.

I''m not sure what Python defines.

Just some ideas. :)

Regards,

Dan

> 
> Just trying to come up with hooks for win32-service.  It looks like
> Perl''s Win32::Daemon defines these:
> 
> start....................The service is starting.
> pause....................The service is entering a paused state.
> continue.................The service is resuming from a paused state.
> stop.....................The service is stopping
> running..................The service is running
> interrogate..............The service is being queried for information.
> shutdown.................The system is being shut down.
> param_change.............There has been a parameter change to the
> system.
> net_bind_add.............A new network binding has been made.
> net_bind_remove..........A network binding has been removed.
> net_bind_enable..........A network binding has been enabled.
> net_bind_disable.........A network binding has been disabled.
> device_event.............A device has generated some event.
> hardware_profile_change..A change has been made to the system''s
hardware
> profile.
> power_event..............A power event has occured (eg change to battery
> power).
> session_change...........There has been a change in session.
> user_defined.............A user defined event has been sent to the
> service.
> 
> We can change the names as we see fit obviously.  Should we also add
> hooks for pause_pending, start_pending, and stop_pending?
> 
> I''m primarily concerned with the start, stop, continue, running
and
> shutdown hooks.  At least that''s where I''d like to start
initially.
> 
> I''m not sure what Python defines.
> 
> Just some ideas. :)
> 
> Regards,
> 
> Dan
> 
I added service control signal hooks in service.c and daemon_test.c
Enjoy and modify code for your taste.
My code may be not suitable for your taste :-)

There was bug in daemon_test.c 
"state==SERVICE_RUNNING" should be "state==RUNNING".

Regards,

Park Heesob



--MIME Multi-part separator--

Dan,
> We can change the names as we see fit obviously.  Should we also add
> hooks for pause_pending, start_pending, and stop_pending?
Yes.
> I''m primarily concerned with the start, stop, continue, running
and
> shutdown hooks.  At least that''s where I''d like to start
initially.
Agree.
> I''m not sure what Python defines.
                              ^^^^^^^^^^^
Take a look at the #defines here:

http://cvs.sourceforge.net/viewcvs.py/*checkout*/pywin32/pywin32/win32/src/win32service.i?rev=1.4

HTH,
-- Shashank

> I added service control signal hooks in service.c and 
> daemon_test.c Enjoy and modify code for your taste. My code 
> may be not suitable for your taste :-)
Nice!

Is there any way we can cut this down from a two part process to a one
part process?  For example, with the current code you would define a
stop hook like this:

class Daemon
   def on_stop
      File.open(''c:\log.txt'',''a+''){ |f|
f.puts "Service stopped" }
   end

   def worker
      evt_hook(CONTROL_STOP) { on_stop }
      ...
   end
end

Can we alter the API such that there are a series of predefined methods
that automatically get called for the appropriate signal?  e.g.

class Daemon
   # This method would automatically be called when CONTROL_STOP signal
was received.
   def on_stop
      File.open(''c:\log.txt'',''a+''){ |f|
f.puts "Service stopped" }
   end

   def worker
      # No need to specify evt_hook
   end
end

In other words, define an "on_stop" method (or whatever we want to
call
it) within the Daemon class that the user can define and is
automatically called when a CONTROL_STOP signal is received?  The only
drawback to this that I can see would be a lot of potential no-op calls
where the user hasn''t explicitly defined the method themselves.

This doesn''t concern me though, because the performance impact should
be
minimal, and generally I''m not worried about signal handling
performance
anyway.  If it takes .001 seconds longer to stop or start a service, so
be it.  I''d rather have the nicer syntax. :)
> There was bug in daemon_test.c 
> "state==SERVICE_RUNNING" should be "state==RUNNING".
Odd, I could have sworn I changed it.  Thanks for the fix. :)

Regards,

Dan

> 
>  > I added service control signal hooks in service.c and 
> > daemon_test.c Enjoy and modify code for your taste. My code 
> > may be not suitable for your taste :-)
> 
> Nice!
> 
> Is there any way we can cut this down from a two part process to a one
> part process?  For example, with the current code you would define a
> stop hook like this:
> 
> class Daemon
>    def on_stop
>       File.open(''c:\log.txt'',''a+''){ |f|
f.puts "Service stopped" }
>    end
> 
>    def worker
>       evt_hook(CONTROL_STOP) { on_stop }
>       ...
>    end
> end
> 
> Can we alter the API such that there are a series of predefined methods
> that automatically get called for the appropriate signal?  e.g.
> 
> class Daemon
>    # This method would automatically be called when CONTROL_STOP signal
> was received.
>    def on_stop
>       File.open(''c:\log.txt'',''a+''){ |f|
f.puts "Service stopped" }
>    end
> 
>    def worker
>       # No need to specify evt_hook
>    end
> end
> 
> In other words, define an "on_stop" method (or whatever we want
to call
> it) within the Daemon class that the user can define and is
> automatically called when a CONTROL_STOP signal is received?  The only
> drawback to this that I can see would be a lot of potential no-op calls
> where the user hasn''t explicitly defined the method themselves.
> 
> This doesn''t concern me though, because the performance impact
should be
> minimal, and generally I''m not worried about signal handling
performance
> anyway.  If it takes .001 seconds longer to stop or start a service, so
> be it.  I''d rather have the nicer syntax. :)
> 
OK, agreed. KISS!
It is up to you.
I know you can modify it for your taste. :)
> > There was bug in daemon_test.c 
> > "state==SERVICE_RUNNING" should be
"state==RUNNING".
> 
> Odd, I could have sworn I changed it.  Thanks for the fix. :)
> 
:)

Regards, 

Park Heesob



--MIME Multi-part separator--