You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[JENKINS-1245] allow termination of subprocesses of cmd.exe #310
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.
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.
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.
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.
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.
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 ?
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)
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.
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...
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?)
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.
Activity
jenkins-infra-bot commentedon Feb 2, 2008
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.
jenkins-infra-bot commentedon Feb 3, 2008
gerhard6:
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
jenkins-infra-bot commentedon Feb 3, 2008
huybrechts:
Raw content of original comment:
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
jenkins-infra-bot commentedon Feb 7, 2008
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.
jenkins-infra-bot commentedon Feb 8, 2008
gerhard6:
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.(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)
jenkins-infra-bot commentedon Feb 8, 2008
akostadinov:
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.
jenkins-infra-bot commentedon Feb 8, 2008
akostadinov:
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
jenkins-infra-bot commentedon Feb 8, 2008
gerhard6:
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
jenkins-infra-bot commentedon Feb 8, 2008
gerhard6:
Raw content of original comment:
I hope, you dont need that article, but it is somehow related:
http://www.duckware.com/tech/java6msvcr71.html
jenkins-infra-bot commentedon Feb 8, 2008
Raw content of original comment:
This is probably just a mistake in choosing the right link mode.
Working on a fix.
jenkins-infra-bot commentedon Feb 8, 2008
Raw content of original comment:
Took a while to minimize DLL w/o dynamic link, but now it's fixed in 1.182.
jenkins-infra-bot commentedon Feb 12, 2008
gerhard6:
Raw content of original comment:
verified here (winxp, hudson-1.183), and it seems to work.
Thanks
jenkins-infra-bot commentedon Jun 10, 2008
mirilovic:
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.
jenkins-infra-bot commentedon Jun 12, 2008
msauer:
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?)
jenkins-infra-bot commentedon Jan 9, 2009
musilt2:
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.
jenkins-infra-bot commentedon Jan 9, 2009
musilt2:
Raw content of original comment:
Created an attachment (id=503)
patch