We have a build step that runs a TestNG suite, with the command looking something like this:
java -jar -Done-jar.main.class=org.testng.TestNG the-jar.jar TheTest.xml
If the process is aborted in any way (manual intervention, Jenkins build timeout, etc.) OR if the agent loses connection from the master long enough to fail the build, then there is a Java process left behind.
This is particularly damaging to us, as we load a DLL in the Java process, locking the file handle. If we attempt the job again, we cannot load the DLL again, meaning that all future builds will fail without manual intervention (killing the leftover process manually).
It is possible to reproduce with ANY java process executed on the Windows agent.
This bug seems similar to JENKINS-26048, but I did not understand from the title/description if it was the same problem or similar symptoms. Feel free to close as duplicate if it is.
- is related to
-
JENKINS-26048 Jenkins no longer cleaning up child processes when build stopped - as of 1.587
-
- Reopened
-
[JENKINS-38807] Jenkins 2.7.4 seems to leave behind Java processes (on Windows agent) if the build is aborted/agent loses connection
Greg Fraley
created issue -
Greg Fraley
made changes -
| Link | New: This issue is related to JENKINS-26048 [ JENKINS-26048 ] |
| Labels | Original: regression | New: regression ux |
| Labels | Original: regression ux | New: ux |
| Description |
Original:
We have a build step that runs a TestNG suite, with the command looking something like this: {code:java} java -jar -Done-jar.main.class=org.testng.TestNG the-jar.jar TheTest.xml {code} If the process is aborted in any way (manual intervention, Jenkins build timeout, etc.) OR if the slave loses connection from the master long enough to fail the build, then there is a Java process left behind. This is particularly damaging to us, as we load a DLL in the Java process, locking the file handle. If we attempt the job again, we cannot load the DLL again, meaning that all future builds will fail without manual intervention (killing the leftover process manually). It is possible to reproduce with ANY java process executed on the Windows slave. This bug seems similar to JENKINS-26048, but I did not understand from the title/description if it was the same problem or similar symptoms. Feel free to close as duplicate if it is. |
New:
We have a build step that runs a TestNG suite, with the command looking something like this: {code:java} java -jar -Done-jar.main.class=org.testng.TestNG the-jar.jar TheTest.xml {code} If the process is aborted in any way (manual intervention, Jenkins build timeout, etc.) OR if the agent loses connection from the master long enough to fail the build, then there is a Java process left behind. This is particularly damaging to us, as we load a DLL in the Java process, locking the file handle. If we attempt the job again, we cannot load the DLL again, meaning that all future builds will fail without manual intervention (killing the leftover process manually). It is possible to reproduce with ANY java process executed on the Windows agent. This bug seems similar to JENKINS-26048, but I did not understand from the title/description if it was the same problem or similar symptoms. Feel free to close as duplicate if it is. |
| Summary | Original: Jenkins 2.7.4 seems to leave behind Java processes (on Windows slave) if the build is aborted/slave loses connection | New: Jenkins 2.7.4 seems to leave behind Java processes (on Windows agent) if the build is aborted/agent loses connection |