Service not sending SIGINT properly to java

[treaz]

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 #41)

[treaz]

Closing this as we're moving to a different wrapper

[oleg-nenashev]

@treaz
Sorry for the missing response. I'm snowed under various assignments, so unfortunately I was unable to timely review the issue.

I'll reopen the issue and investigate what happens when I have some time.

[rsargant]

I have just encountered this very same issue using winsw 1.17 on Windows Server 2012 R2 Data Center. Here is the relevant wrapper log excerpt.

15-05-21 00:31:37 - Starting java -Xmx512m -Xms64m "-XX:OnOutOfMemoryError=taskkill /F /PID %p" "-Dorg.apache.el.parser.SKIP_IDENTIFIER_CHECK=true" "-Dlog4jdbc.debug.stack.prefix=com.tvrc.as" "-Dlog4jdbc.dump.sql.addsemicolon=true" "-Dlog4jdbc.sqltiming.warn.threshold=5000" "-Ddeploy.mode=prod" "-XX:+HeapDumpOnOutOfMemoryError" "-XX:MaxPermSize=128m" "-Dorg.apache.jasper.runtime.BodyContentImpl.LIMIT_BUFFER=true" "-Dorg.apache.jasper.compiler.disablejsr199=true" "-Djava.net.preferIPv4Stack=true" "-Djetty.base=jetty/base/" "-Djetty.home=jetty/home/" -jar jetty/home/start.jar
2015-05-21 00:31:37 - Started 3100
2015-05-21 00:43:58 - Stopping pCare
2015-05-21 00:43:58 - ProcessKill 3100
2015-05-21 00:43:58 - Found child process: 4760 Name: conhost.exe
2015-05-21 00:43:58 - Stopping process 4760
2015-05-21 00:43:58 - Send SIGINT 4760
2015-05-21 00:43:58 - SIGINT to 4760 failed - Killing as fallback
2015-05-21 00:43:58 - Stopping process 3100
2015-05-21 00:43:58 - Send SIGINT 3100
2015-05-21 00:43:58 - SIGINT to 3100 failed - Killing as fallback
2015-05-21 00:43:58 - Finished pCare

I also happen to run this service from the same configuration file on Windows 7 and Server 2008 R2 and I do not encounter this issue. The "Found child process" lines do not appear in the log and the graceful shutdown is successful.

[alexeyvino]

I can confirm I've got the same problem on Windows 8:
2015-05-26 17:21:29 - Starting C:\Program Files\Java\jre7\bin\java.exe -Xrs -Xmx512m -jar "C:\Program Files\MyCompany\MyService\lib\mylib.jar"
2015-05-26 17:21:29 - Started 15116
2015-05-26 17:30:43 - Stopping MyCompany:MyService
2015-05-26 17:30:43 - ProcessKill 15116
2015-05-26 17:30:43 - Found child process: 15076 Name: conhost.exe
2015-05-26 17:30:43 - Stopping process 15076
2015-05-26 17:30:43 - Send SIGINT 15076
2015-05-26 17:30:43 - SIGINT to 15076 failed - Killing as fallback
2015-05-26 17:30:43 - Stopping process 15116
2015-05-26 17:30:43 - Send SIGINT 15116
2015-05-26 17:30:43 - SIGINT to 15116 failed - Killing as fallback
2015-05-26 17:30:43 - Finished MyCompany:MyService

[rsargant]

I have found a workaround for this issue (tested in Windows Server 2012 R2 Standard)
I added <stopparentprocessfirst>true</stopparentprocessfirst> to my configuration file.
The SIGINT to the Java process succeeds now and I can tell from my application logs that an orderly shutdown of the container was performed. There is still a SIGINT issue related to terminating conhost.exe but I don't think I care about it.

New Output

2015-08-11 14:25:38 - Starting java -Xmx512m -Xms64m "-XX:OnOutOfMemoryError=taskkill /F /PID %p" "-Dorg.apache.el.parser.SKIP_IDENTIFIER_CHECK=true" "-Dlog4jdbc.debug.stack.prefix=com.tvrc.as" "-Dlog4jdbc.dump.sql.addsemicolon=true" "-Dlog4jdbc.sqltiming.warn.threshold=5000" "-Ddeploy.mode=prod" "-XX:+HeapDumpOnOutOfMemoryError" "-XX:MaxPermSize=128m" "-Dorg.apache.jasper.runtime.BodyContentImpl.LIMIT_BUFFER=true" "-Dorg.apache.jasper.compiler.disablejsr199=true" "-Djava.net.preferIPv4Stack=true" "-Djetty.base=jetty/base/" "-Djetty.home=jetty/home/" -jar jetty/home/start.jar
2015-08-11 14:25:38 - Started 3728
2015-08-11 14:26:53 - Stopping pCare
2015-08-11 14:26:53 - ProcessKill 3728
2015-08-11 14:26:53 - Found child process: 3516 Name: conhost.exe
2015-08-11 14:26:53 - Stopping process 3728
2015-08-11 14:26:53 - Send SIGINT 3728
2015-08-11 14:27:03 - SIGINT to3728 successful
2015-08-11 14:27:03 - Stopping process 3516
2015-08-11 14:27:03 - Send SIGINT 3516
2015-08-11 14:27:03 - SIGINT to 3516 failed - Killing as fallback
2015-08-11 14:27:03 - Finished pCare

[rocketraman]

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.

[oleg-nenashev]

Maybe it was an issue with wait time handling, which has been fixed in #135 .
It would be great if somebody could test the latest build. It can be taken from https://ci.appveyor.com/project/oleg-nenashev/winsw/build/artifacts

[oleg-nenashev]

@rocketraman @treaz @rsargant I would appreciate if somebody retests and provides results

[treaz]

@oleg-nenashev I can't test anymore since I switched companies and no longer work on windows

[oleg-nenashev]

@treaz thanks for the response anyway! Generally I do not work on Windows as well :(

[alexeyvino]

Same for me :(

…

On Wed, Jan 11, 2017 at 1:25 PM, Oleg Nenashev ***@***.***> wrote: @treaz <https://github.com/treaz> thanks for the response anyway! Generally I do not work on Windows as well :( — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#95 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMCffTq4x8mC7LEAJj8LmoYu_SAil3i2ks5rRNhlgaJpZM4EHHmB> .

-- Alexey

[rocketraman]

@oleg-nenashev Sorry I'm not in a position to test this any more either :-(

[oleg-nenashev]

Just to join the party, I also do not use Windows as a main DEV system. And no Windows in production... Do not regret it much.

I think it makes sense to close this bug for now. If it still exists, somebody can reopen this one or create a new one

[mpana]

@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

[laguiz]

With Winsw version 2.2.0.0 the flag <stopparentprocessfirst>true</stopparentprocessfirst> is still needed. It could be interesting to mention it in documentation : https://github.com/kohsuke/winsw/blob/master/examples/sample-allOptions.xml#L133

Not sure why it's different for Java versus other application. For example I also wrap nginx and it does not need this flag.

I'm using Play 2.6.x and Java 1.8.0_201 on Windows Microsoft Windows Server 2016 Datacenter - 10.0.14393 Build 14393.

Note for others : do not test with myservice.exe test if your server takes some time to start. Do real start and stop to test

[Newenv01]

I faced the same issue however I fixed the problem by running this following command netstat -abno in "cmd" and found the same port number 8080 was listen by Tomcat. So, stopped tomcat in Taskmanager and restarted the below java file with relevant parameters.

" java -Xrs -Xmx256m -Dhudson.lifecycle=hudson.lifecycle.WindowsServiceLifecycle -jar "C:\Program Files (x86)\Jenkins\jenkins.war" --httpPort=8080 --webroot="C:\Program Files (x86)\Jenkins\war
Running from: C:\Program Files (x86)\Jenkins\jenkins.war"

and it's is working fine.

[nxtn]

I think it makes sense to close this bug for now. If it still exists, somebody can reopen this one or create a new one

As far as I can see, people prefer to comment on existing closed issues.

[nxtn]

<stopparentprocessfirst>true</stopparentprocessfirst> fixes this. We'll set its default value to true in 2.x and remove it in 3.x. For more information, see #487.

The Console Window Host (conhost.exe) does not have a console. It's a host process for the console window.

Closing this and all related issues as fixed.