I used Runtime.getRuntime().exec() to start external program in GREG handler, and get its pid. But how I can detect when the GREG stopping or restarting , that I can stop or restart the external program.
If you want to do execute some custom logic during startup or shutdown phases you can use handlers provided in org.wso2.carbon.core package
e.g.
ServerStartupHandler - https://github.com/wso2/carbon-kernel/blob/4.4.x/core/org.wso2.carbon.core/src/main/java/org/wso2/carbon/core/ServerStartupHandler.java
ServerShutdownHandler - https://github.com/wso2/carbon-kernel/blob/4.4.x/core/org.wso2.carbon.core/src/main/java/org/wso2/carbon/core/ServerShutdownHandler.java
ServerRestartHandler - https://github.com/wso2/carbon-kernel/blob/4.4.x/core/org.wso2.carbon.core/src/main/java/org/wso2/carbon/core/ServerRestartHandler.java
Also you may use https://github.com/wso2/carbon-kernel/blob/4.4.x/core/org.wso2.carbon.core/src/main/java/org/wso2/carbon/core/ServerStartupObserver.java to listen to startup events
There is no documented mechanism of doing this. There are some internal mechanisms within the OSGi space where the components can define dependancies to detest if those are started. However, I do not think those are exposed to handler API.
One way to do is to check if you can access a resource successfully from within the handler, and if so, then start the program.
Related
I was writing an application in Play 2.3.7 and when trying to create an actor (using the default Akka.system() of Play) inside the beforeStart overriden method of the Global object, the application crashes with some infinite recursive call of beforeStart, ultimately throwing an exception due to Global object not being initialized. If I create this actor inside the onStart method, then everything goes well.
My "intuition" was: "ok, this actor must be ready before the application receives the first request, so it must be created on beforeStart, not in onStart".
When is Akka.system() ready to use?
Akka.system returns an ActorSystem held by the AkkaPlugin. Therefore, if you want to use it, you must do so after the AkkaPlugin has been initialized. The AkkaPlugin is given priority 1000, which means its started after most other internal plugins (database, evolutions, ..). The Global plugin has priority 10000, which means the AkkaPlugin is available there (and for any plugin with priority > 1000).
Note the warning in the docs about beforeStart:
Called before the application starts.
Resources managed by plugins, such as database connections, are likely not available at this point.
You have to start this in onStart() because beforeStart() is called too early - way before anything like Akka (which is actually a plugin) or any database connections are created. In fact, the documentation for GlobalSettings states:
Resources managed by plugins, such as database connections, are likely not available at this point.
The general guidance (confirmed by this thread) is that onStart() is the place to create your actors. And in practice, that has worked for me as well.
Is it possible to create a windows service to create and maintain another process? Like I'm writing a program, and say a virus killed the process, could I have my window service running and basically 'watching' it? I already have the code for a regular application that stays running and executes a program if it's not currently running, to keep it running.
I've never written a service before, but would it be that hard to just write this simple program, which basically runs a check to see if the process is running, if not, it executes it and sleeps for a few minutes?
Thanks.
Yes, it is possible. It is not uncommon to see third-party apps have watchdog services to keep them running in case of crashes. A service can enumerate running processes using EnumProcesses(), and if the desired executable is not running then start a new copy of it using CreateProcessAsUser().
If the service is the one starting the executable process in the first place, or can find it after an enumeration, one optimization would be to keep an open handle to the process (returned by CreateProcess...(), or use OpenProcess() on the process ID an enumeration returns), and then use a wait function, like WaitForSingleObject(), to detect when the process stops running. That way, you don't have to enumerate processes to find out if the intended process is still running or not.
Is it possible to have a program restart automatically if it crashes?
Something like:
An unhandled exception is thrown.
Release all resources allocated by process.
Start over and call main.
I would like this behavior for a server application I'm working on. If clients miss use the server it can get a std::bac_alloc exception, in which case I would like the server to simply restart instead of crashing and shutting down, thus avoiding manual startup.
I've done this before in Windows by running said program from another program via a win32 CreateProcess call. The other program then waits on the "monitored" process to exit, and calls its CreateProcess() again if it does. You wait for a process to exit by performing a WaitForSingleObject on the process' handle, which you get as one of the return values from your CreateProcess() call.
You will of course want to program in some way to make the monitoring process shut itself and its child process down.
Let Windows be your watchdog. You can call ChangeServiceConfig2 to set the failure actions for your service. (If your server isn't a service, then you're doing it wrong.) Specify SERVICE_CONFIG_FAILURE_ACTIONS for the dwInfoLevel parameter, and in the SERVICE_FAILURE_ACTIONS structure, set lpsaActions to an array of one or more SC_ACTION values. The type you want is SC_ACTION_RESTART.
I did something similar by implementing a watchdog. The watchdog ran as a service and would wait for a ping (called petting the dog) from the monitored process. If the monitored process died due to an exception, watchdog would cleanup and relaunch the application.
In case the application was not responding(no ping in a certain time) the watchdog would kill it and then restart it.
Here is a link to an implementation that you might want to use:
http://www.codeproject.com/KB/security/WatchDog.aspx
(PS: I implemented my own version but I cannot post it here. I found this from a quick google search and have no first hand experience with this particular implementation.)
If you just catch the exception, it should be possible to just restart your server by internal programming logic without completely restarting the whole program.
Like #T.E.D., we've done this in an application we built. Our application is a windows service, so the helper program stops the service (eventually kill it, if it hangs) and start the service again.
I'm writing some dll (on windows in MSVC++2008) which provides some functionality as xmlrpc server. To implement xmlrpc server I'm using xmlrpc-c library.
I can start xmlrpc server in some diffrent ways. More intresting are:
run method - This will run xmlrpc server forever so dll can't control until server is not terminated.
runOnce method - This will run xmlrpc server only to process one RPC. And if there is no request it will wait for that.
I can't keep control in dll for long time. I need to process some RPCs and give back control to program which is using dll. And process next RPCs when dll will get back control again.
runOnce looks ok. But there is possibility that there will be no RPCs to process and it will be waiting for one. That is unacceptable.
There is also one exception:
runOnce aborts waiting for a
connection request and returns
immediately if the process receives a
signal. Note that unless you have a
handler for that signal, the signal
will probably kill the whole process,
so set up a signal handler — even one
that does nothing — if you want to
exploit this. But before Xmlrpc-c 1.06
(June 2006), signals have no effect —
there is no way to make runOnce abort
the wait and return.
Can I use it as workaround go get back control to dll? Is it possible to send signal from dll to themself? How it works on windows?
Or maybe there is some better solution of this issue?
Signals (of the kind that makes an Xmlrpc-c library call abort early) don't exist in Windows.
Best solution is to create new thread for server.
I'm stopping a service in my application wanted to know what is the usage of
ExitProcess and if I should use it
You should never need to use ExitProcess() to stop a service. In fact, you should never need to use ExitProcess() at all.
Services are deeply intertwined with the SCM, and if a service that it thinks should be running just vanishes it will take some action to repair it. In extreme cases, it will force the system to reboot.
The correct way to stop a service is to use the documented API to ask the SCM to ask the service to stop. It often takes several seconds for this process to complete as the service itself usually needs to a clean shutdown after asking its worker threads to finish up and halt.
The privileges required to interact with the SCM are less dangerous than that required to end an arbitrary process, but neither is usually granted outside of the Administrators group.
Edit: A comment asked about stopping a service from inside itself.
That can be a tough call, especially if the service is in some kind of unfortunate state. The service and the SCM absolutely have to agree that the service is stopping, or the SCM will take the recovery action that was configured for the service.
I do have a complete implementation of a service that might serve as an alternative point of view for how to handle some of these things. It is LuaService and is a framework that allows a (single worker thread) service to be implemented in pure Lua aside from the LuaService executable itself. Its reference manual attempts to fully document the internals, as well as document some of the details of a service's lifetime that are otherwise documented through the interaction of various articles on MSDN.
Look into the OpenSCManager(), OpenService() and ControlService() Windows API calls. Note that your program may not have the necessary permissions to call these, so elevation may be necessary - see Service Security and Access Rights for further information.
There is also an example how to stop a service.
I see that none of the posts here really answers the original question.
RBerteig wrote: "In extreme cases, it will force the system to reboot."
This is nonsense. This might happen if you kill WinLogon.exe, but is not valid for services in general.
If you stop a service from another application you will obviously use
ControlService(mh_Service, SERVICE_CONTROL_STOP, &k_Status);
But what if a service decides that it's work is done and it wants to shut down itself?
The correct way is this (if your service does not run in a shared process):
void cService::Suicide()
{
// Inform the Service Control Manager that the service is stopped now.
SERVICE_STATUS k_Status = {0};
k_Status.dwServiceType = SERVICE_WIN32_OWN_PROCESS;
k_Status.dwControlsAccepted = SERVICE_ACCEPT_STOP | SERVICE_ACCEPT_SHUTDOWN;
k_Status.dwCurrentState = SERVICE_STOPPED;
SetServiceStatus(mh_Service, &k_Status);
ExitProcess(0);
}
I use this code in my service class and it works perfectly on any version of Windows from XP to Windows 10.
!Obviously you should do any cleanup work that is required before calling this function!
ExitProcess is for ending the process itself (much like ExitThread ends a thread). This is used to end a process (program or DLL), though Microsoft don't recommend it for ending a DLL.
If you are trying to stop yourself (you are the process), you can use ExisProcess, though I would recommend a cleaner shutdown, to make sure everything is cleanly stopped. ExitProcess, like ExitThread, stops without unwinding the stack, so no destructors are called.
From within a service, you stop based on an external signal. You could respond to that by calling ExitProcess, but it would probably be better to have some form of shutdown that closes anything necessary and logs this.