if I have a distributed.Client instance can I use that to shutdown the remote cluster? i.e. to kill all workers and also shutdown the scheduler?
If that can't be done using the Client instance is there another way other than manually killing each remote process?
There is no client function specifically for this.
The scheduler has a close() method which you could call using run_on_scheduler thus
c.run_on_scheduler(lambda dask_scheduler=None:
dask_scheduler.close() & sys.exit(0))
which will tell workers to disconnect and shutdown, and will close all connections before terminating the process. Note that this raises an error in the client, since the connection is broken without a reply. There are probably more elegant ways.
Note that the right way to do this is probably to interact with one of the deployment cluster managers. For example, LocalCluster has a user-facing close() method that you can call directly.
--EDIT--
client.shutdown() is now available.
When I am sending HUP signal to inetd so that it rereads the new inetd.conf file, what I want is, the processes controlled by the inetd process should also restart, so that it can read the new command line parameters added to the inetd.conf file as part of the change.
I know I can search for the running process and kill it, but is there a standard way to do this. I could not find anything over the Internet.
The standard inetd included in NetBSD does not manage the processes it starts (except for single-threaded services, i.e. those with "wait" flags) -- it just starts them. Each child process services one active connection and then exits when done (i.e. when the connection is closed). In the general case it would be very unwise to kill such processes early without very good reason -- for example consider the case where your current login session (where you tell inetd to reload) was opened to a service controlled by inetd (e.g. sshd).
If you really want to kill processes handling active current connections then you will have to write some helper script of your own to do that, though perhaps pkill will suffice.
Using Windows phone 8.1 silverlight
Background Task is a WinRT Task.
The problem I'm facing is I'm running a background task and I want the background task to exit when the foreground App is closed or terminated.
I know when closing the foreground App I can use the Application_closing method to write to isolated storage to communicate with the background task.
But the real question is how do I handle the event when the foreground App goes from suspension state to terminated state. Or even if is it possible for the background task to query the status of the foreground App to the OS.
Thanks you.
Unfortunately there is no way to get information about your app going from the suspended into the terminated state. That's why most articles on MSDN explicitely state that you have to save any session related data before an app is suspended.
You should always save user information and app data in the suspending event because Windows doesn’t notify apps before it terminates them. This is important because termination can occur under a variety of circumstances, such as when Windows needs to free memory or the device loses (battery) power.
https://msdn.microsoft.com/en-us/magazine/jj660301.aspx
What you could do is to implement some kind of ping mechanism where your foregound app constantly writes timestamps to the isolated storage. If these
pings exceed a predefined timestamp you can assume your app was terminated and exit the background task.
Is there any way my Windows program (C/C++) can receive a notification when it is being killed from Taskmgr.exe? It does not appear to receive any special Windows Messages - it just terminates.
I don't want to stop it from terminating, I just want to write a notification of some kind that it was manually terminated.
Thanks.
If it's a full windows app, you should get WM_QUIT in your message pump right before the application quits.
As MSDN states: http://msdn.microsoft.com/en-us/library/windows/desktop/ms632641(v=vs.85).aspx
This isn't posted to a window's message queue, you can only retrieve it in your main message pump.
This is only when it quits cleanly. If the process is killed, this never happens.
A way you can detect it being killed on next launch, is to have a file be created on start-up and destroyed on shutdown, If the file still exists on the next start up you know that the process was killed, but not whether it was killed due to an error or because it was killed at a users request.
If you need to know immediately when your process is killed the only way I know of is to use another process as a watchdog. If you use OpenProcess() to get a handle to the process in question, you can wait on that handle (via WaitForSingleObject or similar), and the handle will be signalled when the process terminates. You'll need to do some coordination with the target process in order to track whether the shutdown was clean or forcible.
While implementing an applicative server and its client-side libraries in C++, I am having trouble finding a clean and reliable way to stop client processes on server shutdown on Windows.
Assuming the server and its clients run under the same user, the requirements are:
the solution should work in the following cases:
clients may each feature either a console or a gui.
user may be unprivileged.
clients may be or become unresponsive (infinite loop, deadlock).
clients may or may not be children of the server (direct or indirect).
unless prevented by a client-side defect, clients shall be allowed the opportunity to exit cleanly (free their ressources, sync some data to disk...) and some reasonable time to do so.
all client return codes shall be made available (if possible) to the server during the shutdown procedure.
server shall wait until all clients are gone.
As of this edit, the majority of the answers below advocate the use of a shared memory (or another IPC mechanism) between the server and its clients to convey shutdown orders and client status. These solutions would work, but require that clients successfully initialize the library.
What I did not say, is that the server is also used to start the clients and in some cases other programs/scripts which don't use the client library at all. A solution that did not rely on a graceful communication between server and clients would be nicer (if possible).
Some time ago, I stumbled upon a C snippet (in the MSDN I believe) that did the following:
start a thread via CreateRemoteThread in the process to shutdown.
had that thread directly call ExitProcess.
Unfortunately now that I'm looking for it, I'm unable to find it and the search results seem to imply that this trick does not work anymore on Vista. Any expert input on this ?
If you use thread, a simple solution is to use a named system event, the thread sleeps on the event waiting for it to be signaled, the control application can signal the event when it wants the client applications to quit.
For the UI application it (the thread) can post a message to the main window, WM_ CLOSE or QUIT I forget which, in the console application it can issue a CTRL-C or if the main console code loops it can check some exit condition set by the thread.
Either way rather than finding the client applications an telling them to quit, use the OS to signal they should quit. The sleeping thread will use virtually no CPU footprint provided it uses WaitForSingleObject to sleep on.
You want some sort of IPC between clients and servers. If all clients were children, I think pipes would have been easiest; since they're not, I guess a server-operated shared-memory segment can be used to register clients, issue the shutdown command, and collect return codes posted there by clients successfully shutting down.
In this shared-memory area, clients put their process IDs, so that the server can forcefully kill any unresponsive clients (modulo server privileges), using TerminateProcess().
If you are willing to go the IPC route, make the normal communication between client and server bi-directional to let the server ask the clients to shut down. Or, failing that, have the clients poll. Or as the last resort, the clients should be instructed to exit when the make a request to server. You can let the library user register an exit callback, but the best way I know of is to simply call "exit" in the client library when the client is told to shut down. If the client gets stuck in shutdown code, the server needs to be able to work around it by ignoring that client's data structures and connection.
Use PostMessage or a named event.
Re: PostMessage -- applications other than GUIs, as well as threads other than the GUI thread, can have message loops and it's very useful for stuff like this. (In fact COM uses message loops under the hood.) I've done it before with ATL but am a little rusty with that.
If you want to be robust to malicious attacks from "bad" processes, include a private key shared by client/server as one of the parameters in the message.
The named event approach is probably simpler; use CreateEvent with a name that is a secret shared by the client/server, and have the appropriate app check the status of the event (e.g. WaitForSingleObject with a timeout of 0) within its main loop to determine whether to shut down.
That's a very general question, and there are some inconsistencies.
While it is a not 100% rule, most console applications run to completion, whereas GUI applications run until the user terminates them (And services run until stopped via the SCM). Hence, it's easier to request a GUI to close. You send them the equivalent of Alt-F4. But for a console program, you have to send them the equivalent of Ctrl-C and hope they handle it. In both cases, you simply wait. If the process sticks around, you then shoot it down (TerminateProcess) and pray that the damage is limited. But your HDD can fill up with temporary files.
GUI application in general do not have exit codes - where would they go? And a console process that is forcefully terminated by definition does not exit, so it has no exit code. So, in a server shutdown scenario, don't expect exit codes.
If you've got a debugger attached, you generally can't shutdown the process from another application. That would make it impossible for debuggers to debug exit code!