3

Our group has long running processes which run daily. The processes are typically started at 9pm on any given day and run until 7pm the next day. Thus they typically run 22hrs/day. They are started by scheduled tasks on servers under a particular generic user ID, and they start and run regardless of whether or not that user ID is logged on. Thus, they are windowless console executables.

The tasks orchestrate computations running on a large server farm. Generally these controlling tasks run uninterrupted for the full 22hrs/day. However, we often have a need to stop and restart these processes. Because they control a multitude of tasks running on our server farm, it is important that they be shut down cleanly, so that they can stop and shut down all the server farm processes. Which brings me to our problem.

The controlling process has been programmed to respond to ctrl-C and ctrl-break signals. This works fine when the process is manually started in a console where we have access to the console and can "type" ctrl-c or ctrl-break in the console window. However, as mentioned, the processes typically run as windowless scheduled tasks. Hence we cannot "type" anything into a non-existent console window. Because they are console processes that execute without a logon process, the also must be able to execute in a completely windowless environment. So, how do we set up the process to listen for a shut-down signal?

While the process does indeed listen for a ctrl-C and ctrl-break signal, I can see no way to send that signal to a process. This seems to be a fundamental problem in Windows, or am I wrong? I am aware of SendSignal.exe, but so far have been unable to get it to work. It fails as follows:

>SendSignal 26320
Sending signal to process 26320...
CreateRemoteThread failed with 0x00000005.
StartRemoteThread failed with 0x00000005.
0x00000005 == Access is denied.

Trying "taskkill" without -F results in:

>taskkill /PID 24840
ERROR: The process with PID 24840 could not be terminated.
Reason: This process can only be terminated forcefully (with /F option).

All other "kill" functions kill the process immediately rather than sending a signal.

One possible solution would be a file-watch based solution: create a watch for some modification of a specific file. But this is a hack and we would prefer to do it with appropriate signaling. Has anyone solved this issue? It seems to be so very basic a functionality, and it is certainly trivial to do it in a Unix environment. Surely Microsoft has provided SOME mechanism to allow clean shut down of a windowless executable?

I am aware of the thread below, whose question is virtually identical (save for the specification of why the answer is necessary, i.e. why one needs to be able to do this for a windowless, console-less process), but there is no answer there excpet for "use SendSignal", which, as I said, does not work for us:

Can I send a ctrl-C (SIGINT) to an application on Windows?

There are other similar questions, but no answers as yet.

Any help appreciated.

Community
  • 1
  • 1
David I. McIntosh
  • 2,038
  • 4
  • 23
  • 45
  • 1
    http://msdn.microsoft.com/en-us/library/windows/desktop/ms683155%28v=vs.85%29.aspx – Hans Passant Aug 05 '14 at 15:43
  • In the link you sent, the key line is "Only those processes in the group that share the same console as the calling process receive the signal". The implication is that GenerateConsoleCtrlEvent is useless and is not a solution to my problem above. – David I. McIntosh Aug 07 '14 at 21:09
  • Congratulations, now you understand why pursuing this approach is pointless. Clears your mind to find the proper solution, use a named event or pipe to signal the process. – Hans Passant Aug 07 '14 at 21:22
  • 1
    I understand that the GenerateConsoleCtrlEvent is useless. What I have seen tells me that there seems to be no way at all to signal a process with the CTRL_BREAK_EVENT, and you seem to be confirming this. But I am just still in shock - was MS really so stupid as to not provide this functionality, or am I missing something? I am not sure using a pipe would be useful, because we never know if we may have to signal the process (we generally don't), but perhaps I don't understand your suggestion. The suggestion of a named event sounds possibly intriguing, thanks for that. – David I. McIntosh Aug 08 '14 at 03:55
  • did you find the solution yet? I am running into the same issue like you. – Sabin Mar 08 '17 at 23:39
  • No. In the end, we are using a "signal file" - the process creates the file, and checks every so often for its presence. Deletion of the file is a signal to the process to shut down. In some ways, this is incredibly ugly. On the other hand, we can shut down the process remotely simply by deleting the file - no need to invoke a process on the running machine. So it has its advantages. Never the less, I'm still convinced that it can be done and I just haven't had the time to figure it out. – David I. McIntosh Mar 15 '17 at 03:09
  • 1
    If you want to try and alternative to `SendSignal.exe` you can try [windows-kill](https://github.com/alirdn/windows-kill) but I don't know if it will work better for you. Your problem might be that the user who wants to do the killing is different to the user running your long running processes though... – Anon Mar 17 '18 at 08:25
  • You could try [this solution](https://stackoverflow.com/a/15281070) which uses `GenerateConsoleCtrlEvent` – Marcono1234 Jul 25 '19 at 15:21

1 Answers1

-1

[Upgrading @Anon's comment to an answer for visibility]

windows-kill worked perfectly and managed to resolve access denial issues faced with SendSignal. A privileged user would have to run it as well of course.

windows-kill also supports both ctrl-c and ctrl-break signals.

aybassiouny
  • 559
  • 5
  • 14