• Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Critical Critical
    • durable-task-plugin
    • None
    • Platform: PC, OS: Windows XP

      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.

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

          akostadinov added a 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

          akostadinov added a 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

          gerhard6 added a 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

          gerhard6 added a 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

          gerhard6 added a comment -

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

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

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

          Kohsuke Kawaguchi added a comment - This is probably just a mistake in choosing the right link mode. Working on a fix.

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

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

          gerhard6 added a comment -

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

          Thanks

          gerhard6 added a comment - verified here (winxp, hudson-1.183), and it seems to work. Thanks

          mirilovic added a comment -

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

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

          msauer added a 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?)

          msauer added a 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?)

          musilt2 added a 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.

          musilt2 added a 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.

          musilt2 added a comment -

          Created an attachment (id=503)
          patch

          musilt2 added a comment - Created an attachment (id=503) patch

            kohsuke Kohsuke Kawaguchi
            gerhard6 gerhard6
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: