When I deploy a new version of a background worker how does the old worker exit? It the process killed? Is there some kind of graceful termination option?
friism is correct, right now the process is forcefully terminated using TerminateProcess.
Related
I've got a service that needs to be resarted, but all attempts to kill it fail.
I have tried everything i've found online and nothing has seemed to work.
The core issue seems to be that Services is holding onto the process and not allowing it to be killed
ERROR: The process with PID 11204 (child process of PID 572) could not be terminated.
Reason: There is no running instance of the task.
this happens when i try to force kill the task using taskkill/f /pid 11204 /t
PID 572 is services, so i cannot kill it without crashing windows.
There is also an Interactive Services detection that is activating but just leads to a blank screen i can't exit out of (since the process is dead) but turning this off still doesn't allow me to kill it.
I've found similar issues around but none seem to have the problem of the program being a child of services, and so can't kill the parent.
Is a system restart the ONLY option here? This is a production server and so restarting has to be done only at scheduled downtime, so looking for other options.
Services should be controlled via services APIs, or SCcommand-line tool. Try SC stop command.
On a call to ControlService[Ex] with SERVICE_CONTROL_STOP, explicitly from your SW or from SC tool, service's Handler[Ex] should receive SERVICE_CONTROL_STOP. At this point service should
Stop all its own started threads and free its own allocated resources
If it takes long, should also call SetServiceStatus with SERVICE_STOP_PENDING before that
Call SetServiceStatus with SERVICE_STOPPED to inform the system that is is no longer running
Return from Handler[Ex]
If the service was the only service in its process, StartServiceCtrlDispatcher is likely to return shortly, and at this point service process should exit. If there are other services in the process, StartServiceCtrlDispatcher will not return, and process should not exit, but the service being stopped is considered stopped anyway.
If I kill -QUIT the master resource manager process, it restarts and then runs normally. But if I kill -ABRT the master resource manager process, it restarts but processes on HAWQ restart. So how does HAWQ handle different kill signals?
There are multiple processes started by postmaster
1. Resource Manager
2. master logger process
3. stats collector process
4. writer process
5. checkpoint process
6. seqserver process
7. WAL Send Server process
8. DFS Metadata Cache Process.
For the SIGNAL response, different processes have different handling.
master logger process is independent with other processes, other process restart will not influence it, and its restart will not influence other processes too. For SIGQUIT, it will ignore. For SIGABORT and SIGKILL, it will restart.
stats collector process doesn't influence other processes, but will be influenced by other process's restart. For signal SIGQUIT, SIGABORT, or SIGKILL, it will restart itself.
Resource Manager process, For signal SIGQUIT, it will restart itself, for signal SIGABORT and SIGKILL, will restart all other sub-processes.
The other 5 processes, for signal SIGQUIT, SIGABORT, or SIGKILL, will restart itself and all other sub-processes except master logger process.
HAWQ Resource Manager catches the signal SIGQUIT, and registers a function named quitResManager to handle the signal. The process will quit peaceably. But for the signal SIGABRT, the Resource manager will generate coredump according to the definition of SIGABORT.
Since the Resource manager process is forked by postmaster, the postmaster process keeps an eye on watching its subprocess, and will restart the sub-process itself if finding subprocess normally quits, but will restart all the sub-processes if finding error in subprocess.
So you can see the Resource Manager process itself is restarted after you send kill -QUIT, but see all the processes on the HAWQ master restarted after you send kill -ABORT.
I wonder if hawq resource manager process is killed by SIGKILL, whether parent postmaster process will also exit?
#huan, parent postmaster will not restart itself if any sub-processes meets error. But if itself meets error, it will not restart anyone, all the sub-processes will be killed.
Is there any way in ruby to determine if a background worker is running?
For instance, i have a server that works a queue in delayed job and i would like to ensure 4 workers are on it and spin up a new worker process if one has either stalled or quit.
From the command line, crontab -lgives a list of all currently running jobs.
From the Rails console, Delayed::Job.all will give you a list of all currently running jobs.
Delayed Job also has a list of lifecycle methods which you can access:
http://www.rubydoc.info/github/collectiveidea/delayed_job/Delayed/Lifecycle
the usual way to do that is to use an external watchdog process. you can use Monit or God
I created some workers with coffee-resque and was trying to view workers using the ruby version of resque-web and only saw intermittent workers flash in and out.
I noticed that coffee-resque untracks workers while paused. Is that the intended behavior? This made it so that resque web only listed flashing intermittent workers and they always had a status of waiting when they did appear, even though that was when they were processing.
Am I doing it wrong or is there a suggested way of monitoring the worker queues?
Also, is there a way to clean up the inactive orphaned worker keys in redis if the worker process failed and didn't do a graceful untrack on exit?
I recently provided a pull request that fixed this issue. It has been accepted into coffee-resque and a new version was released.
https://github.com/technoweenie/coffee-resque/issues/17
This fix was released as 0.1.6.
I have a windows C++ application (app.exe). When the app is closed, I need to perform some cleanup tasks specific to my application. What happens when this process (app.exe) is killed through the Task Manager. Assuming that the application is still responsive, can I somehow handle this situation in my app.exe?
I am looking for something similar to how kill <pid> in Linux will send the SIGTERM signal to the process indicated by pid. I could then register my own signal handler for SIGTERM and perform the cleanup.
There are two ways to kill application in Task Manager.
Killing through Applications tab would roughly be equivalent of SIGTERM. Application may intercept it and do more processing, since it's basically sending a "close window" message. Message to catch is WM_CLOSE.
Killing through Processes tab would roughly be equivalent of SIGKILL. There is nothing you can do to intercept that, short of monitoring user's actions in Task Manager's listbox and End Process button, or having a watchdog process that will see when the first one is killed.
Alternatively, design the application in a way that does not require cleanup, or in a way that it will perform cleanup at startup.
I think you will need another PID that is monitoring the PID of your app.exe and does the necessary work at the time.
That depends, if the user chooses to "End Task" your application you will be notified and you can handle it see this.
but if the user chooses to end the process, you have no way to handle it in your application. the easiest way would be a second process or you can inject into process manager and hook the TerminateProcess API.