NT Service Questions
in [Win32 Kernel]
|
From: Hector Santos on 2 Aug 2010 15:30 m wrote: > In principal it should work fine. The only thing to be careful of is > that your monitoring service SYNSERVER.EXE may be able to establish a > connection, but the worker service's connection may fail (i.e. out of > memory, network congestion etc.). In this case, a retry is likely > appropriate. Good point. However, in general, I would normally lean towards this being an extraordinary situation (especially after a clean boot up). So RPC clients startup will be expected to be successful with a successful SYNCSERVER startup. But the point is well taken that a mishap can occur after the syncserver is successful and begins to start each of the RPC clients. I think the only possible (realistic) issue is a RPC 17xx errors (broken communications). See below. From an application setup error standpoint, we tell all customers to not enable NT Services until they are happy with their setup startup as a desktop - so they can see all GUI diagnostic errors/warnings popups related to configuration, etc. > Effectively this design implements the same logic at a whole process > level, witch is less efficient from an OS point of view, but might be > easier from a code maintenance and operational point of view The good thing here is that the all clients are single sourced with the RPC Client/Server DLL API that does the discovery, connection and context creation, marshalling of client communications channels, etc. Although rare to occur (less today, more in the past), the broken RPC communications is trapped with the DLL so this situation can be handled in single source manner. I like the idea because SYNCSERVER would be a service version of our existing WCSTART.EXE deskop tool that allows operators to prepare a dependency startup of desktop processes. Here WCSTART starts the local RPC server or skips this if REMOTE computer name is provided and pools/waits for RPC client connection before it begins to start the dependency tree of processes. So SYNCSERVER would be WCSTART with relatively changes: - GUI removed, - Reads the same WCSTART registry data (but this needs to be moved to HKLM), and - Instead of CreateProcess() it calls the SCM start service API. Sorry for the misc details, but I am also writing this as a note to myself to summarize the work. :) -- HLS
From: m on 3 Aug 2010 19:06
Sounds like you have a solution that should work "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:u8EdcknMLHA.2276(a)TK2MSFTNGP06.phx.gbl... > m wrote: >> In principal it should work fine. The only thing to be careful of is >> that your monitoring service SYNSERVER.EXE may be able to establish a >> connection, but the worker service's connection may fail (i.e. out of >> memory, network congestion etc.). In this case, a retry is likely >> appropriate. > > Good point. However, in general, I would normally lean towards this being > an extraordinary situation (especially after a clean boot up). So RPC > clients startup will be expected to be successful with a successful > SYNCSERVER startup. > > But the point is well taken that a mishap can occur after the syncserver > is successful and begins to start each of the RPC clients. I think the > only possible (realistic) issue is a RPC 17xx errors (broken > communications). > See below. > > From an application setup error standpoint, we tell all customers to not > enable NT Services until they are happy with their setup startup as a > desktop - so they can see all GUI diagnostic errors/warnings popups > related to configuration, etc. > >> Effectively this design implements the same logic at a whole process >> level, witch is less efficient from an OS point of view, but might be >> easier from a code maintenance and operational point of view > > The good thing here is that the all clients are single sourced with the > RPC Client/Server DLL API that does the discovery, connection and context > creation, marshalling of client communications channels, etc. > > Although rare to occur (less today, more in the past), the broken RPC > communications is trapped with the DLL so this situation can be handled in > single source manner. > > I like the idea because SYNCSERVER would be a service version of our > existing WCSTART.EXE deskop tool that allows operators to prepare a > dependency startup of desktop processes. Here WCSTART starts the local RPC > server or skips this if REMOTE computer name is provided and pools/waits > for RPC client connection before it begins to start the dependency tree of > processes. > > So SYNCSERVER would be WCSTART with relatively changes: > > - GUI removed, > > - Reads the same WCSTART registry data (but this needs to be moved > to HKLM), and > > - Instead of CreateProcess() it calls the SCM start service API. > > Sorry for the misc details, but I am also writing this as a note to myself > to summarize the work. :) > > -- > HLS |