Skip to content

[JENKINS-1245] allow termination of subprocesses of cmd.exe #310

Open

Description

@jenkins-infra-bot

Problem: from within a hudson "windows batch task", my bat file in turns
invokes. e.g. a java.exe. When I terminate this hudson task with [x], the
java.exe is NOT terminated, and must be manually killed.
Quite a nasty thing, as "normal" users of the web-interface don't understand,
and the next build perhaps then fails, as the old build process still has some
files open etc.

Pls note the thread and Kohsukes last reply in
https://hudson.dev.java.net/servlets/ReadMsg?listName=users&msgNo=967

I assume that approach would solve the problem by using the windows-tool "pskill -t"
Proposal: make the "kill" command configurable in hudson, and document, how to
solve the problem. The hudson server administrator shall then download pskill
himself and configure hudson.
This way, you dont have problems with licensing.


Originally reported by gerhard6, imported from: allow termination of subprocesses of cmd.exe
  • assignee: kohsuke
  • status: Reopened
  • priority: Critical
  • component(s): durable-task-plugin
  • resolution: Fixed
  • resolved: 2008-02-08T19:27:27+00:00
  • votes: 0
  • watchers: 6
  • imported: 2025-12-09
Raw content of original issue

Problem: from within a hudson "windows batch task", my bat file in turns invokes. e.g. a java.exe. When I terminate this hudson task with [x], the java.exe is NOT terminated, and must be manually killed. Quite a nasty thing, as "normal" users of the web-interface don't understand, and the next build perhaps then fails, as the old build process still has some files open etc.

Pls note the thread and Kohsukes last reply in https://hudson.dev.java.net/servlets/ReadMsg?listName=users&msgNo=967

I assume that approach would solve the problem by using the windows-tool "pskill -t" Proposal: make the "kill" command configurable in hudson, and document, how to solve the problem. The hudson server administrator shall then download pskill himself and configure hudson. This way, you dont have problems with licensing.

  • environment: Platform: PC, OS: Windows XP
1 attachment

Activity

  1. jenkins-infra-bot commented on Feb 2, 2008

    @jenkins-infra-bot
    Author
    kohsuke:
    • Original comment link
    • Raw content of original comment:

      One of the things I try very hard in Hudson is not to introduce configuration items as much as possible.

      I think this falls into that category, too. We should be writing a freely redistributable "kill-the-tree" tool, and we should bundle that in Hudson, so that things just work.

      Kill-the-tree tool is shouldn't be too difficult to write.

    One of the things I try very hard in Hudson is not to introduce configuration
    items as much as possible.

    I think this falls into that category, too. We should be writing a freely
    redistributable "kill-the-tree" tool, and we should bundle that in Hudson, so
    that things just work.

    Kill-the-tree tool is shouldn't be too difficult to write.

  2. jenkins-infra-bot commented on Feb 3, 2008

    @jenkins-infra-bot
    Author
    gerhard6:
    • Original comment link
    • Raw content of original comment:

      Hello kohsuke.

      To some extend, I understand your concerns about configuration-hell, and I agree, that one of the key strengths of hudson is it's ease of use.

      On the other hand, I would like to be solution-oriented, and simply plug the things together, an my job is done....

      I've looked thru the internet, and, unfortunately, didnt find any valuable pieces which could help. (http://forums.atlassian.com/message.jspa?messageID=257241765 is somehow interesting, but not ready-to-use. In addition, I'm "only" java-programmer and not very used to windows/c code...)

      Proposal: Following Convention over Configuration (like in maven): Keep it simple for the normal case, and have an option to step away from the "normal" path. Translated to the current problem: have the already existing "normal" way to kill/terminate hudson jobs, and, in addition, have the option to ovveride it - maybe NOT via the "nice" Web Gui, but perhaps on a simple property-file level.

      Assuming, that I provide a patch for this, how good are the chances, that it will be incorporated into the code stream ?

      Thanks for listening, Gerhard

    Hello kohsuke.

    To some extend, I understand your concerns about configuration-hell, and I
    agree, that one of the key strengths of hudson is it's ease of use.

    On the other hand, I would like to be solution-oriented, and simply plug the
    things together, an my job is done....

    I've looked thru the internet, and, unfortunately, didnt find any valuable
    pieces which could help.
    (http://forums.atlassian.com/message.jspa?messageID=257241765 is somehow
    interesting, but not ready-to-use. In addition, I'm "only" java-programmer and
    not very used to windows/c code...)

    Proposal: Following Convention over Configuration (like in maven): Keep it
    simple for the normal case, and have an option to step away from the "normal" path.
    Translated to the current problem: have the already existing "normal" way to
    kill/terminate hudson jobs, and, in addition, have the option to ovveride it -
    maybe NOT via the "nice" Web Gui, but perhaps on a simple property-file level.

    Assuming, that I provide a patch for this, how good are the chances, that it
    will be incorporated into the code stream ?

    Thanks for listening, Gerhard

  3. jenkins-infra-bot commented on Feb 3, 2008

    @jenkins-infra-bot
    Author
    huybrechts:

    I found source for another tool to kill a process tree in Windows. Unfortunately
    it doesn't explicitly state a license.

    http://www.alexfedotov.com/articles/killproc.asp

  4. jenkins-infra-bot commented on Feb 7, 2008

    @jenkins-infra-bot
    Author
    kohsuke:
    • Original comment link
    • Raw content of original comment:

      Based on the article, I implemented a DLL in http://winp.dev.java.net/ and integrated that in Hudson.

      Implemented in 1.181. A verification would be appreciated.

    Based on the article, I implemented a DLL in http://winp.dev.java.net/ and
    integrated that in Hudson.

    Implemented in 1.181. A verification would be appreciated.

  5. jenkins-infra-bot commented on Feb 8, 2008

    @jenkins-infra-bot
    Author
    gerhard6:
    • Original comment link
    • Raw content of original comment:

      Hello kohsuke (thanks a lot for handling this issue so quickly )

      tried it, got an unsatisfiedlinkerror, see below. My colleague told be that perhaps another dll (MSVCR90.dll) is missing, because you obviously use a quite new compiler/linker:

      > output of dumpbin /dependents winp.dll > > Microsoft (R) COFF/PE Dumper Version 8.00.50727.762 > Copyright (C) Microsoft Corporation. All rights reserved. > > > Dump of file winp.dll > > File Type: DLL > > Image has the following dependencies: > > KERNEL32.dll > ADVAPI32.dll > MSVCR90.dll

      Output of my build, which I tried to terminate:

      ... [INFO] Nothing to compile - all classes are up to date FATAL: C:\Dokumente und Einstellungen\mpa989\Lokale Einstellungen\Temp\winstone\mpa989\hudson-1.181.war\WEB-INF\lib\winp.dll: Diese Anwendung konnte nicht gestartet werden, weil die Anwenungskonfiguration nicht korrekt ist. Zur Problembehebung sollten Sie die Anwendung neu installieren java.lang.UnsatisfiedLinkError: C:\Dokumente und Einstellungen\mpa989\Lokale Einstellungen\Temp\winstone\mpa989\hudson-1.181.war\WEB-INF\lib\winp.dll: Diese Anwendung konnte nicht gestartet werden, weil die Anwenungskonfiguration nicht korrekt ist. Zur Problembehebung sollten Sie die Anwendung neu installieren at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1751) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1647) at java.lang.Runtime.load0(Runtime.java:770) at java.lang.System.load(System.java:1005) at org.jvnet.winp.Native.load(Native.java:62) at org.jvnet.winp.Native.<clinit>(Native.java:22) at org.jvnet.winp.WinProcess.<init>(WinProcess.java:22) at hudson.Proc$LocalProc.destroy(Proc.java:166) at hudson.Proc$LocalProc.join(Proc.java:150) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:61) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:35)

    Hello kohsuke
    (thanks a lot for handling this issue so quickly )

    tried it, got an unsatisfiedlinkerror, see below.
    My colleague told be that perhaps another dll (MSVCR90.dll) is missing, because
    you obviously use a quite new compiler/linker:

    > output of dumpbin /dependents winp.dll
    >
    > Microsoft (R) COFF/PE Dumper Version 8.00.50727.762
    > Copyright (C) Microsoft Corporation. All rights reserved.
    >
    >
    > Dump of file winp.dll
    >
    > File Type: DLL
    >
    > Image has the following dependencies:
    >
    > KERNEL32.dll
    > ADVAPI32.dll
    > MSVCR90.dll

    Output of my build, which I tried to terminate:

    ...
    [INFO] Nothing to compile - all classes are up to date
    FATAL: C:\Dokumente und Einstellungen\mpa989\Lokale
    Einstellungen\Temp\winstone\mpa989\hudson-1.181.war\WEB-INF\lib\winp.dll: Diese
    Anwendung konnte nicht gestartet werden, weil die Anwenungskonfiguration nicht
    korrekt ist. Zur Problembehebung sollten Sie die Anwendung neu installieren
    java.lang.UnsatisfiedLinkError: C:\Dokumente und Einstellungen\mpa989\Lokale
    Einstellungen\Temp\winstone\mpa989\hudson-1.181.war\WEB-INF\lib\winp.dll: Diese
    Anwendung konnte nicht gestartet werden, weil die Anwenungskonfiguration nicht
    korrekt ist. Zur Problembehebung sollten Sie die Anwendung neu installieren
    at java.lang.ClassLoader$NativeLibrary.load(Native Method)
    at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1751)
    at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1647)
    at java.lang.Runtime.load0(Runtime.java:770)
    at java.lang.System.load(System.java:1005)
    at org.jvnet.winp.Native.load(Native.java:62)
    at org.jvnet.winp.Native.(Native.java:22)
    at org.jvnet.winp.WinProcess.(WinProcess.java:22)
    at hudson.Proc$LocalProc.destroy(Proc.java:166)
    at hudson.Proc$LocalProc.join(Proc.java:150)
    at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:61)
    at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:35)

  6. jenkins-infra-bot commented on Feb 8, 2008

    @jenkins-infra-bot
    Author
    akostadinov:
    • Original comment link
    • Raw content of original comment:

      I implemented a very limited bash script to do kill on UNIX platforms. But it's limited to that it either can't kill processes with dead parent processes or based on etime it kills any procs started after the job execution started so useful only on slaves with a single executor.

      I checked the behavior on windows as well and with regard to ppid the issue is the same - a proc loses ppid once its parent no longer exists.

      Do you believe this is not a limitation with your approach?

      btw. I've heard special kernel patches are needed for linux so you can track for sure if a process was started by or by a child of another one.

      Stale processes are big concern for our deployment so I'll be happy to help as I can.

    I implemented a very limited bash script to do kill on UNIX platforms. But it's
    limited to that it either can't kill processes with dead parent processes or
    based on etime it kills any procs started after the job execution started so
    useful only on slaves with a single executor.

    I checked the behavior on windows as well and with regard to ppid the issue is
    the same - a proc loses ppid once its parent no longer exists.

    Do you believe this is not a limitation with your approach?

    btw. I've heard special kernel patches are needed for linux so you can track for
    sure if a process was started by or by a child of another one.

    Stale processes are big concern for our deployment so I'll be happy to help as I
    can.

  7. jenkins-infra-bot commented on Feb 8, 2008

    @jenkins-infra-bot
    Author
    akostadinov:
    • Original comment link
    • Raw content of original comment:

      Adding to cc. Just FYI the script requires bash and ps. It works on RHEL3/4/5, solaris 9/10 and HP-UX 10.x

    Adding to cc. Just FYI the script requires bash and ps. It works on RHEL3/4/5,
    solaris 9/10 and HP-UX 10.x

  8. jenkins-infra-bot commented on Feb 8, 2008

    @jenkins-infra-bot
    Author
    gerhard6:
    • Original comment link
    • Raw content of original comment:

      One more note on the versions of the missing msvcrXX.dll. I've seen, that in jre\lib, there is msvcr71.dll. My colleague (a Windows-C guru) told me, that the winp.dll code only uses quite simple calls into msvcr, so the "older" version could be ok.

      So, I hope you can tell your linker to use that dll. hopefully, it will then be found during runtime...

      hope it helps, Gerhard

    One more note on the versions of the missing msvcrXX.dll.
    I've seen, that in jre\lib, there is msvcr71.dll.
    My colleague (a Windows-C guru) told me, that the winp.dll code only uses quite
    simple calls into msvcr, so the "older" version could be ok.

    So, I hope you can tell your linker to use that dll. hopefully, it will then be
    found during runtime...

    hope it helps, Gerhard

  9. jenkins-infra-bot commented on Feb 8, 2008

    @jenkins-infra-bot
    Author
    gerhard6:

    I hope, you dont need that article, but it is somehow related:
    http://www.duckware.com/tech/java6msvcr71.html

  10. jenkins-infra-bot commented on Feb 8, 2008

    @jenkins-infra-bot
    Author
    kohsuke:
    • Original comment link
    • Raw content of original comment:

      This is probably just a mistake in choosing the right link mode. Working on a fix.

    This is probably just a mistake in choosing the right link mode.
    Working on a fix.

  11. jenkins-infra-bot commented on Feb 8, 2008

    @jenkins-infra-bot
    Author
    kohsuke:
    • Original comment link
    • Raw content of original comment:

      Took a while to minimize DLL w/o dynamic link, but now it's fixed in 1.182.

    Took a while to minimize DLL w/o dynamic link, but now it's fixed in 1.182.

  12. jenkins-infra-bot commented on Feb 12, 2008

    @jenkins-infra-bot
    Author
    gerhard6:
    • Original comment link
    • Raw content of original comment:

      verified here (winxp, hudson-1.183), and it seems to work.

      Thanks

    verified here (winxp, hudson-1.183), and it seems to work.

    Thanks

  13. jenkins-infra-bot commented on Jun 10, 2008

    @jenkins-infra-bot
    Author
    mirilovic:
    • Original comment link
    • Raw content of original comment:

      Unfortunately it works just for Master - but it doesn't work on Slaves ;( Adding Max, he will provide more details.

    Unfortunately it works just for Master - but it doesn't work on Slaves ;(
    Adding Max, he will provide more details.

  14. jenkins-infra-bot commented on Jun 12, 2008

    @jenkins-infra-bot
    Author
    msauer:
    • Original comment link
    • Raw content of original comment:

      We have tried this in our cluster. but it does not seem to work properly for windows XP Professional slaves. I've enabled the property per slave and even re-compiled hudson source and replaced the 'Boolean.getBoolean ...' with 'true' to make sure, re-distributed slavejars and the processes still not get terminated.

      When debugging, ProcessTreeKiller.get detects 'Windows' properly, but the instance is never created (probably because of the library, the static initializer?)

    We have tried this in our cluster. but it does not seem to work properly for windows XP Professional
    slaves. I've enabled the property per slave and even re-compiled hudson source and replaced the
    'Boolean.getBoolean ...' with 'true' to make sure, re-distributed slavejars and the processes still not get
    terminated.

    When debugging, ProcessTreeKiller.get detects 'Windows' properly, but the instance is never created
    (probably because of the library, the static initializer?)

  15. jenkins-infra-bot commented on Jan 9, 2009

    @jenkins-infra-bot
    Author
    musilt2:
    • Original comment link
    • Raw content of original comment:

      still does not work in our master-slave config; problem is exact as msauer described. Have a working fix (to workaround problem), tested in my environment. Attaching patch. Please integrate.

    still does not work in our master-slave config; problem is exact as msauer
    described. Have a working fix (to workaround problem), tested in my environment.
    Attaching patch. Please integrate.

  16. jenkins-infra-bot commented on Jan 9, 2009

    @jenkins-infra-bot
    Author
    musilt2:
    • Original comment link
    • Raw content of original comment:

      Created an attachment (id=503) patch

    Created an attachment (id=503)
    patch

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions