[
https://jira.codehaus.org/browse/SUREFIRE-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=286961#comment-286961
]
nkeywal commented on SUREFIRE-773:
----------------------------------
It's easy to reproduce with a sleep like this:
{noformat}
public class Test7 {
@Test
public void test71() throws Exception {
Thread.sleep(100 * 1000); // longer than forkedProcessTimeoutInSeconds
}
}
{noformat}
This test will survive to the timeout (and here will finish alone after 100
seconds). On unix, its ppid will be 1.
The library calls the java Process#destroy on timeout, but destroy does not
kill the subprocesses.
It seems to be a known java issue:
http://bugs.sun.com/view_bug.do?bug_id=4770092
But the solution won't come from this, from the evaluation in 2005:
{noformat}
The fundamental problem here is that, unlike Unix, Windows does that maintain
parent-child relationships between processes. A process can kill its own
immediate children, but unless you make other arrangements to obtain the
information, can't kill any 'grand-children' because it has no way of finding
them.
Fully emulating the Unix behaviour is probably
impossible. Note that Unix emulation environments on Windows, like Cygwin,
suffer from the same problem. Any fix would be difficult.
Even if we could figure out how to fix this, we might choose not to do so
for the usual reason -- compatibility.
{noformat}
> surefire forked processes not always killed after timeout
> ---------------------------------------------------------
>
> Key: SUREFIRE-773
> URL: https://jira.codehaus.org/browse/SUREFIRE-773
> Project: Maven Surefire
> Issue Type: Bug
> Components: process forking
> Affects Versions: 2.8
> Environment: 64 bit RHEL 5.5 , 64-bit Java 1.6.0_23
> Reporter: David Biesack
>
> Our forked JUnit/surefire processes are not always stopping correctly when
> timing out within a Maven build
> (running inside our Jenkins CI server, ver 1.425).
> The maven build finishes and Jenkins shows a failed/unstable build.
> These running processes cause problems later, because the tests may be
> holding a resource like a port, and subsequent rebuilds fail because the
> tests fail.
> For example, even though no Maven builds are currently running, ps shows
> about a dozen Java processes running,
> with commands such as:
> {noformat}
> /usr/local/java-1.6_23/jre/bin/java -Xms1g -Xmx5g
> -Djava.library.path=/u/jenkinsci/.hudson/jobs/rtolap.jtt.tests/workspace/target/lib
> \
> -jar
> /u/jenkinsci/.hudson/jobs/rtolap.jtt.tests/workspace/target/surefire/surefirebooter1374560535780866887.jar
> \
>
> /u/jenkinsci/.hudson/jobs/rtolap.jtt.tests/workspace/target/surefire/surefire65313...
> /usr/local/java-1.6_23/jre/bin/java -Xmx2g -Xms1g
> -Djava.library.path=/u/jenkinsci/.hudson/jobs/rtolap/workspace/target/lib \
> -jar
> /u/jenkinsci/.hudson/jobs/rtolap/workspace/target/surefire/surefirebooter6814971258434039335.jar
> \
>
> /u/jenkinsci/.hudson/jobs/rtolap/workspace/target/surefire/surefire5806103969370259371tmp
> /u/jenkinsci/...
> ...
> {noformat}
> We have our Maven surefire preferences set to fork the tests (via a parent
> pom)
> {code:xml|title=pom.xml excerpt}
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-surefire-plugin</artifactId>
> <version>2.8</version>
> <configuration>
> <forkMode>once</forkMode>
>
> <forkedProcessTimeoutInSeconds>720</forkedProcessTimeoutInSeconds>
> </configuration>
> </plugin>
> {code}
> I suspect the timeout is the problem - i.e. perhaps the test is timing out
> and the attempt to kill the forked process
> fails, leaving it running.
> Has anyone seen something similar and/or know how to fix this so that
> surefire *really* kills the process?
> When this happens, doing
> kill <processid>
> (logged in as the process owner) usually does not work, but
> kill -9 <processid>
> does.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
