Sending Ctrl+C to process started with exec
I'm trying to send a CTRL-C event to a java process started with exec.
cmd := exec.Command("javaw", "-cp", "burst.jar;conf", "brs.Burst")
cmd.Dir = burstCmdPath
cmd.Env = append(os.Environ())
err = cmd.Start()
...
cmd.Process.Signal(syscall.SIGINT)
Unfortunately, the SIGINT-signal does not work on windows.
I do not want to KILL the process. I just want to close it gracefully with CTRL-C.
I tried several things:
- Calling taskkill: Process does only react to forced kill.
Using win32-API:
...
d, err := syscall.LoadDLL("kernel32.dll")
p, e := d.FindProc("GenerateConsoleCtrlEvent")
r, _, e := p.Call(syscall.CTRL_C_EVENT, uintptr(cmd.Process.Pid))
if r == 0 {
fmt.Print("GenerateConsoleCtrlEvent: %vn", e)
}
...
Does not throw any errors, but does not work either.
If you open burst.jar inside a shell, you can just press CTRL+C to signal a shutdown, but why not with exec?
Any ideas?
windows go
add a comment |
I'm trying to send a CTRL-C event to a java process started with exec.
cmd := exec.Command("javaw", "-cp", "burst.jar;conf", "brs.Burst")
cmd.Dir = burstCmdPath
cmd.Env = append(os.Environ())
err = cmd.Start()
...
cmd.Process.Signal(syscall.SIGINT)
Unfortunately, the SIGINT-signal does not work on windows.
I do not want to KILL the process. I just want to close it gracefully with CTRL-C.
I tried several things:
- Calling taskkill: Process does only react to forced kill.
Using win32-API:
...
d, err := syscall.LoadDLL("kernel32.dll")
p, e := d.FindProc("GenerateConsoleCtrlEvent")
r, _, e := p.Call(syscall.CTRL_C_EVENT, uintptr(cmd.Process.Pid))
if r == 0 {
fmt.Print("GenerateConsoleCtrlEvent: %vn", e)
}
...
Does not throw any errors, but does not work either.
If you open burst.jar inside a shell, you can just press CTRL+C to signal a shutdown, but why not with exec?
Any ideas?
windows go
A process can send Ctrl+C or Ctrl+Break to a process group (not necessarily an individual process) only if the sending process is attached to the same console (i.e. conhost.exe instance). The simplest group is 0, which sends the event to all processes attached to the console, including the sender (which must ignore the event). If a process is the lead of a group (i.e. created with the flagCREATE_NEW_PROCESS_GROUP
), by default it has Ctrl+C completely disabled (no handler is called), unless manually enabled. Ctrl+Break can't be ignored in the same way, so it's the more reliable of the two.
– eryksun
Nov 12 at 2:10
If the parent is a GUI process without a console, it can easily attach to the child's console viaAttachConsole
. Or it can preallocate its own console viaAllocConsole
and have the child inherit it. If the parent and child have a different console, it's more complicated since the parent will have to start a process such as cmd.exe to keep its console referenced, then useFreeConsole
andAttachConsole
twice in order to temporarily attach to the child's console and then attach back to its original console.
– eryksun
Nov 12 at 2:14
"Interrupt is not implemented on Windows; using it with os.Process.Signal will return an error." golang.org/pkg/os/#Signal
– Peter
Nov 12 at 7:18
add a comment |
I'm trying to send a CTRL-C event to a java process started with exec.
cmd := exec.Command("javaw", "-cp", "burst.jar;conf", "brs.Burst")
cmd.Dir = burstCmdPath
cmd.Env = append(os.Environ())
err = cmd.Start()
...
cmd.Process.Signal(syscall.SIGINT)
Unfortunately, the SIGINT-signal does not work on windows.
I do not want to KILL the process. I just want to close it gracefully with CTRL-C.
I tried several things:
- Calling taskkill: Process does only react to forced kill.
Using win32-API:
...
d, err := syscall.LoadDLL("kernel32.dll")
p, e := d.FindProc("GenerateConsoleCtrlEvent")
r, _, e := p.Call(syscall.CTRL_C_EVENT, uintptr(cmd.Process.Pid))
if r == 0 {
fmt.Print("GenerateConsoleCtrlEvent: %vn", e)
}
...
Does not throw any errors, but does not work either.
If you open burst.jar inside a shell, you can just press CTRL+C to signal a shutdown, but why not with exec?
Any ideas?
windows go
I'm trying to send a CTRL-C event to a java process started with exec.
cmd := exec.Command("javaw", "-cp", "burst.jar;conf", "brs.Burst")
cmd.Dir = burstCmdPath
cmd.Env = append(os.Environ())
err = cmd.Start()
...
cmd.Process.Signal(syscall.SIGINT)
Unfortunately, the SIGINT-signal does not work on windows.
I do not want to KILL the process. I just want to close it gracefully with CTRL-C.
I tried several things:
- Calling taskkill: Process does only react to forced kill.
Using win32-API:
...
d, err := syscall.LoadDLL("kernel32.dll")
p, e := d.FindProc("GenerateConsoleCtrlEvent")
r, _, e := p.Call(syscall.CTRL_C_EVENT, uintptr(cmd.Process.Pid))
if r == 0 {
fmt.Print("GenerateConsoleCtrlEvent: %vn", e)
}
...
Does not throw any errors, but does not work either.
If you open burst.jar inside a shell, you can just press CTRL+C to signal a shutdown, but why not with exec?
Any ideas?
windows go
windows go
edited Nov 12 at 1:55
asked Nov 12 at 1:49
ee2marine
11
11
A process can send Ctrl+C or Ctrl+Break to a process group (not necessarily an individual process) only if the sending process is attached to the same console (i.e. conhost.exe instance). The simplest group is 0, which sends the event to all processes attached to the console, including the sender (which must ignore the event). If a process is the lead of a group (i.e. created with the flagCREATE_NEW_PROCESS_GROUP
), by default it has Ctrl+C completely disabled (no handler is called), unless manually enabled. Ctrl+Break can't be ignored in the same way, so it's the more reliable of the two.
– eryksun
Nov 12 at 2:10
If the parent is a GUI process without a console, it can easily attach to the child's console viaAttachConsole
. Or it can preallocate its own console viaAllocConsole
and have the child inherit it. If the parent and child have a different console, it's more complicated since the parent will have to start a process such as cmd.exe to keep its console referenced, then useFreeConsole
andAttachConsole
twice in order to temporarily attach to the child's console and then attach back to its original console.
– eryksun
Nov 12 at 2:14
"Interrupt is not implemented on Windows; using it with os.Process.Signal will return an error." golang.org/pkg/os/#Signal
– Peter
Nov 12 at 7:18
add a comment |
A process can send Ctrl+C or Ctrl+Break to a process group (not necessarily an individual process) only if the sending process is attached to the same console (i.e. conhost.exe instance). The simplest group is 0, which sends the event to all processes attached to the console, including the sender (which must ignore the event). If a process is the lead of a group (i.e. created with the flagCREATE_NEW_PROCESS_GROUP
), by default it has Ctrl+C completely disabled (no handler is called), unless manually enabled. Ctrl+Break can't be ignored in the same way, so it's the more reliable of the two.
– eryksun
Nov 12 at 2:10
If the parent is a GUI process without a console, it can easily attach to the child's console viaAttachConsole
. Or it can preallocate its own console viaAllocConsole
and have the child inherit it. If the parent and child have a different console, it's more complicated since the parent will have to start a process such as cmd.exe to keep its console referenced, then useFreeConsole
andAttachConsole
twice in order to temporarily attach to the child's console and then attach back to its original console.
– eryksun
Nov 12 at 2:14
"Interrupt is not implemented on Windows; using it with os.Process.Signal will return an error." golang.org/pkg/os/#Signal
– Peter
Nov 12 at 7:18
A process can send Ctrl+C or Ctrl+Break to a process group (not necessarily an individual process) only if the sending process is attached to the same console (i.e. conhost.exe instance). The simplest group is 0, which sends the event to all processes attached to the console, including the sender (which must ignore the event). If a process is the lead of a group (i.e. created with the flag
CREATE_NEW_PROCESS_GROUP
), by default it has Ctrl+C completely disabled (no handler is called), unless manually enabled. Ctrl+Break can't be ignored in the same way, so it's the more reliable of the two.– eryksun
Nov 12 at 2:10
A process can send Ctrl+C or Ctrl+Break to a process group (not necessarily an individual process) only if the sending process is attached to the same console (i.e. conhost.exe instance). The simplest group is 0, which sends the event to all processes attached to the console, including the sender (which must ignore the event). If a process is the lead of a group (i.e. created with the flag
CREATE_NEW_PROCESS_GROUP
), by default it has Ctrl+C completely disabled (no handler is called), unless manually enabled. Ctrl+Break can't be ignored in the same way, so it's the more reliable of the two.– eryksun
Nov 12 at 2:10
If the parent is a GUI process without a console, it can easily attach to the child's console via
AttachConsole
. Or it can preallocate its own console via AllocConsole
and have the child inherit it. If the parent and child have a different console, it's more complicated since the parent will have to start a process such as cmd.exe to keep its console referenced, then use FreeConsole
and AttachConsole
twice in order to temporarily attach to the child's console and then attach back to its original console.– eryksun
Nov 12 at 2:14
If the parent is a GUI process without a console, it can easily attach to the child's console via
AttachConsole
. Or it can preallocate its own console via AllocConsole
and have the child inherit it. If the parent and child have a different console, it's more complicated since the parent will have to start a process such as cmd.exe to keep its console referenced, then use FreeConsole
and AttachConsole
twice in order to temporarily attach to the child's console and then attach back to its original console.– eryksun
Nov 12 at 2:14
"Interrupt is not implemented on Windows; using it with os.Process.Signal will return an error." golang.org/pkg/os/#Signal
– Peter
Nov 12 at 7:18
"Interrupt is not implemented on Windows; using it with os.Process.Signal will return an error." golang.org/pkg/os/#Signal
– Peter
Nov 12 at 7:18
add a comment |
active
oldest
votes
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53255064%2fsending-ctrlc-to-process-started-with-exec%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53255064%2fsending-ctrlc-to-process-started-with-exec%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
A process can send Ctrl+C or Ctrl+Break to a process group (not necessarily an individual process) only if the sending process is attached to the same console (i.e. conhost.exe instance). The simplest group is 0, which sends the event to all processes attached to the console, including the sender (which must ignore the event). If a process is the lead of a group (i.e. created with the flag
CREATE_NEW_PROCESS_GROUP
), by default it has Ctrl+C completely disabled (no handler is called), unless manually enabled. Ctrl+Break can't be ignored in the same way, so it's the more reliable of the two.– eryksun
Nov 12 at 2:10
If the parent is a GUI process without a console, it can easily attach to the child's console via
AttachConsole
. Or it can preallocate its own console viaAllocConsole
and have the child inherit it. If the parent and child have a different console, it's more complicated since the parent will have to start a process such as cmd.exe to keep its console referenced, then useFreeConsole
andAttachConsole
twice in order to temporarily attach to the child's console and then attach back to its original console.– eryksun
Nov 12 at 2:14
"Interrupt is not implemented on Windows; using it with os.Process.Signal will return an error." golang.org/pkg/os/#Signal
– Peter
Nov 12 at 7:18