Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Service not sending SIGINT properly to java

See original GitHub issue

I have a “Hello world” class (https://gist.github.com/treaz/19c8fb4a90e1cb4b9448) running as a service powered by winsw 1.17.

Stopping the service (from windows) does not work as expected (graceful shutdown). I see the following in the logs:

2015-04-23 18:47:52 - Started 18060
2015-04-23 18:47:56 - Stopping testService
2015-04-23 18:47:56 - ProcessKill 18060
2015-04-23 18:47:57 - Found child process: 6540 Name: conhost.exe
2015-04-23 18:47:57 - Stopping process 6540
2015-04-23 18:47:57 - Send SIGINT 6540
2015-04-23 18:47:57 - SIGINT to 6540 failed - Killing as fallback
2015-04-23 18:47:57 - Stopping process 18060
2015-04-23 18:47:57 - Send SIGINT 18060
2015-04-23 18:47:57 - SIGINT to 18060 failed - Killing as fallback
2015-04-23 18:47:57 - Finished testService

I was expecting this to work in 1.17 (according to this https://github.com/kohsuke/winsw/issues/41)

Issue Analytics

State:
Created 8 years ago
Comments:18 (8 by maintainers)

Top GitHub Comments

2reactions

rocketramancommented, Nov 11, 2016

Same issue here. My service wrapper runs a batch file (created by the gradle application plugin). Unfortunately, Windows doesn’t have the equivalent of exec in bash, so cmd stays in the process tree of the started service, as well as the actual java process.

Using <stopparentprocessfirst>true</stopparentprocessfirst> as suggested by @rsargant does seem to work, but not super-cleanly: the wrapper still has lots of errors about missing / already killed processes:

2016-11-11 14:46:54 - Stopping myapp
2016-11-11 14:46:54 - ProcessKill 21024
2016-11-11 14:46:54 - Found child process: 1144 Name: conhost.exe
2016-11-11 14:46:54 - Found child process: 41304 Name: java.exe
2016-11-11 14:46:54 - Stopping process 21024
2016-11-11 14:46:54 - Send SIGINT 21024
2016-11-11 14:46:55 - SIGINT to21024 successful
2016-11-11 14:46:55 - Stopping process 1144
2016-11-11 14:46:55 - Send SIGINT 1144
2016-11-11 14:46:55 - SIGINT to 1144 failed - Killing as fallback
2016-11-11 14:46:55 - Stopping process 41304
2016-11-11 14:46:55 - Process 41304 is already stopped
2016-11-11 14:46:55 - Finished myapp

I guess this is relying on the java process receiving the SIGINT via propagation from the parent process. Maybe conhost and cmd need special handling? i.e. ignore them, kill other process first (in this case java), then kill conhost and cmd only if necessary.

1reaction

mpanacommented, Jan 17, 2017

@oleg-nenashev I have tested the latest build on Windows 10, however I’m seeing the same warnings in the wrapper log and application event log. The workaround suggested <stopparentprocessfirst>true</stopparentprocessfirst> makes it so the Java process is stopped first (gracefully), but we’re still failing to SIGINT conhost.exe

Top Results From Across the Web

Service not sending SIGINT properly to java · Issue #95

The SIGINT to the Java process succeeds now and I can tell from my application logs that an orderly shutdown of the container...

Kill -SIGINT not working from java but working from terminal

I start a c program from java which collect data from a usb device and write to a file . like Below Runtime...

signals - Why would Ctrl-C behave differently than kill -2

If the program consists of several processes, pressing Ctrl + C sends SIGINT to all the processes in the process group. You can...

Process being sent SIGINT when started using Upstart

Whenever a "CTRL-C" character (0x02) was received, the kernel generated the SIGINT and sent it to the program. This issue wasn't happening from ......

Java SDK ContinueAsNew and concurrent signals

The workflow I'm working on has to continue as new and propagate the workflow state when it gets enough signals. The case I'm...