[Nut-upsdev] [nut-commits] svn commit r2704 - in branches/windows_port: . common drivers include scripts scripts/Windows server

[Frédéric Bohé]

On dim., 2010-11-28 at 10:33 -0500, Charles Lepple wrote:
> Date: Fri, 26 Nov 2010 13:28:47 +0000
> > Subject: svn commit r2704 - in branches/windows_port: . common  
> > drivers include scripts scripts/Windows server
> > Author: fbohe-guest
> > Date: Fri Nov 26 13:28:46 2010
> > New Revision: 2704
> > URL: http://trac.networkupstools.org/projects/nut/changeset/2704
> >
> > Log:
> > Change the "full services" approach to a more POSIX one.
> > We now have only one Windows service in charge of starting/stopping  
> > the relevant NUT processes. It's a Windows replacement for the init  
> > script.
> > This service is also a proxy for processes to write to Windows event  
> > log. So only one service has to be registered to be able to log event.
> 
> As I understand it, one of the design goals of the Windows service  
> subsystem is to monitor processes and restart them when they fail.  
> While I understand that there are valid reasons for consolidating all  
> of NUT into a single service, that sounds like it would make it harder  
> to notice if upsd, upsmon or a driver falls over. You may want to  
> simulate a driver failure (kill the process) and see how that affects  
> the rest of NUT.

We indeed lose the Service Controller ability to monitor and restart
services as needed. But it's still pretty easy to monitor all running
processes through the task manager and kill them as needed. 
Actually the nut service calls CreateProcess for each relevant nut's
binaries. So they appear as regular processes in the task manager.

Sorry for the late answer but we have long discussions with Arnaud
determining which way is the best but I am still unsure. 
Each way has its pros and cons. What make the decision is that in this
early phase we are closer to the linux behavior using regular processes
instead of services. This may ease the porting work and eventually the
maintenance work. It will not be too complicated to switch back to full
services mode in the future if this finally makes more sense.




--------------------------------------------------------------------------