I have an old Windows Service written in Borland C++ Builder that I need to extend so that it can shutdown itself under certain conditions.
If I shutdown the service manually via the service control manager, it shuts down properly without any problems. So I thought, calling this->DoShutdown(); would be sufficient (this being an instance derived from TService). But this leaves the service in the state "Shutting down...". I could call ExitProcess afterwards, but this creates an entry in the event log that the service has been shut down unexpectedly.
So what is the proper way to make a Borland C++ Windows service shut down itself?
DoShutdown() is called by TService when it receives a SERVICE_CONTROL_SHUTDOWN request from the SCM while Windows is being shut down. DoShutdown() is not intended to be called directly in user code.
The easiest way to have your service terminate itself is to call its Controller() method (either directly, or via its global ServiceController() function), passing either SERVICE_CONTROL_STOP or SERVICE_CONTROL_SHUTDOWN in the CtrlCode parameter. Let the service handle the request as if it had come from the SCM, so it can act accordingly.
Related
We'd like to perform occasional configuration refreshes on some of our servers, but we'd prefer that that operation wasn't exposed via a web-service, but rather that the infrastructure guys could call a command via the JBoss CLI to do a refresh.
Is it possible to create new commands / node operations that are exposed via the CLI? Googling seems to show only various methods of accessing the existing operations, and this page, which is a bit light on details of how it's called.
We have some custom implementation ICommunicationListener and in our tests we find out that during application update the CloseAsync method of the listener is not invoked. In VS when we close app it is invoked. This is important for us because we are suspecting that it cussing our troubles during update of the application – it sometimes fails so we have to write a script that delete service and type from cluster and then installation is not failing. Rolling back on failed installation was always on node where service with ICommunicationListener existed.
Is this a know problem? How to force closing on update?
I have a .NET 4.6.2 console application I want to host in Service Fabric.
My application is listening on console input events for administration tasks.
The most important one is 'q' to stop the application - but in a graceful manner.
Is it somehow possible to also have this functionality in Service Fabric with a guest executable?
Of course not on 'q button pressed' but rather on service deleted or whatever events there are.
If there is no way to achieve this kind of integration with a guest executable - which project template do you recommend to build upon?
Service Fabric sends a Ctrl-C signal to the guest executable process before killing it, allowing for graceful shutdown. You can use the Console.CancelKeyPress event or the Win32 SetConsoleCtrlHandler function to get a notification. Note the exe must be compiled as a console app for this to work.
In your stateful or stateless service class:
class MyService : StatefulService /* or StatelessService */
{
protected override Task OnCloseAsync(CancellationToken cancellationToken)
{
// your graceful shutdown code goes here
}
}
But execution of that method is not guaranteed, for instance when the hosting VM unexpectedly dies.
One way to do this, would be to programmatically delete the service when you're done with it, using DeleteServiceAsync
You can recreate it too, using CreateServiceAsync
The reason I'm asking is I would like to use the out-of-proc mode, but I cannot install a service on each user's workstation, only on a central server. Is the communication between event source and listener service an ETW thing, or is there some kind of RPC I could use?
Yes, the out-of-process mode works by using ETW. All ETW events are system wide so the service just has to listen to ETW events.
ETW only works locally and does not offer a remote solution you could use. Your options are to install a service on each workstation, listen to ETW events (here or here) and forward them to your server with a RPC solution you build yourself. Using MSMQ comes to mind. Or have your application forward the events to your server directly so you don't need the service. Either way, you will have to build it yourself.
To add to Lars' answer, you could also log to SQL. There is a SQL sink you can use but like everything else, to get the most customized fit, you would build your own (or inherit from another class to give you a good starting point). Be careful though. Not all sinks are created the same. They all have their pros and cons. For example, with SQL and Azure sinks, you have to worry about high latency. The XML formatter doesn't write the root starting and ending node so it's not well-formed xml. Whatever reads that file would have to provide them. Good luck!
So basically what I'm trying to do is to have a number of additional parameters (namely SERVICENAME and SERVICEDISPLAYNAME) in the installer of my application (which runs a service) instead of hard-coding them in the installer. The installation runs fine with this change. However the problem I have is when I run a silent uninstall. It appears that the Service Control does not stop the service before removing it from the machine and I get a dialog box telling me that the service is still running and asking me if I want the service to be stopped before uninstalling it. What should I do to make it work (i.e. make the service control to stop the service automatically before removing it)?
The ServiceControl Element is just an abstraction for the underlying ServiceControl Table. Neither "do" anything. Instead, they merely express what needs to be done. The stopping of services is performed by the StopServices Action which gets it's orders from the aforementioned table.
In Windows Installer, properties are not persisted automatically after an installation is complete. If you log the installer you will likely find that your SERVICENAME property is null and the StopServices action doesn't know what to do with that.
Take a look at the following:
The WiX toolset's "Remember Property" pattern
If you implement this pattern, the data for SERVICENAME should be restored during the uninstall and the