Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-3105

Configuration UI to disable process tree killer selectively

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Open (View Workflow)
    • Priority: Trivial
    • Resolution: Unresolved
    • Component/s: core
    • Labels:
      None
    • Environment:
      Platform: Sun, OS: Solaris
    • Similar Issues:

      Description

      Due to fix https://hudson.dev.java.net/issues/show_bug.cgi?id=2729, I can't
      restart my tomcat instance with using a script which worked fine before 1.283.
      My script called fastRestart.sh is :
      PWD=`pwd`
      cd $PWD
      #BUILD_ID="dontKillMe catalina.sh start"
      #BUILD_ID="dontKillMe ./startup.sh"
      echo $BUILD_ID
      kill -9 `cat ./tomcat.pid` && ./startup.sh

      My hudson job do :
      BUILD_ID=dontKillMe startup.sh && cd
      /local/dotw/tomcat-dev-ota-ah/apache-tomcat-6.0.14/bin && ./fastRestart.sh

      job console output :
      started
      [workspace] $ /bin/sh -xe
      /local/dotw/tmp/hudson-tmp/hudson3776950102996593394.sh
      BUILD_ID=dontKillMe startup.sh
      + cd /local/dotw/tomcat-dev-ota-ah/apache-tomcat-6.0.14/bin
      + ./fastRestart.sh
      + pwd
      PWD=/local/dotw/tomcat-dev-ota-ah/apache-tomcat-6.0.14/bin
      + cd /local/dotw/tomcat-dev-ota-ah/apache-tomcat-6.0.14/bin
      + echo dontKillMe startup.sh
      dontKillMe startup.sh
      + cat ./tomcat.pid
      + kill -9 9822
      + ./startup.sh
      finished: SUCCESS

      Here the tomcat has been killed and restarted but immediatly stop due to fix for
      2729.
      Is there any other workaround ?
      IMHO we should have a flag when running a script which "don't kill child
      processes" (to preserve a minimum of backward compatibility and a minimum of
      some jobs/scripts rewriting)

      Thanks

      Olivier

        Attachments

          Issue Links

            Activity

            Hide
            olamy Olivier Lamy added a comment -

            I have used the option "This build is parameterized" and add a "String
            Parameter" with Name=BUILD_ID and Default Value=dontKillMe.
            And now it works.
            BTW having a checkbox which says "don't kill child processes" could be more easy.

            Show
            olamy Olivier Lamy added a comment - I have used the option "This build is parameterized" and add a "String Parameter" with Name=BUILD_ID and Default Value=dontKillMe. And now it works. BTW having a checkbox which says "don't kill child processes" could be more easy.
            Hide
            mdonohue mdonohue added a comment -
                • Issue 3125 has been marked as a duplicate of this issue. ***
            Show
            mdonohue mdonohue added a comment - Issue 3125 has been marked as a duplicate of this issue. ***
            Hide
            gj gj added a comment -

            +1 on the checkbox/option idea; using parameterized or modifying the scripts as suggested isn't exactly
            intuitive

            Show
            gj gj added a comment - +1 on the checkbox/option idea; using parameterized or modifying the scripts as suggested isn't exactly intuitive
            Hide
            mdonohue mdonohue added a comment -

            I think this would best be handled by a plugin that adds a UI element for each
            project, or each build step even, that disables the process tree killer. I don't
            think this applies to enough users to add it to core.

            The BUILD_ID environment variable has been working well for most users.

            Show
            mdonohue mdonohue added a comment - I think this would best be handled by a plugin that adds a UI element for each project, or each build step even, that disables the process tree killer. I don't think this applies to enough users to add it to core. The BUILD_ID environment variable has been working well for most users.
            Hide
            m_broida m_broida added a comment - - edited

            Details on this workaround work, please?

            Does it prevent intentionally killing/aborting a build?

            Can a build step in the job just set a BUILD_ID envvar?
            Is the specific value "dontKillMe" required, or will any value work?

            Adding a parameter to every one of our many jobs (and new ones) would be a hassle, even if users could accept a default value.
            Can the BUILD_ID envvar be set in the overall Jenkins configuration to affect all Jenkins jobs?
            Can the BUILD_ID envvar be set at the OS level to affect all Jenkins jobs?

            We have had to restrict many of our jobs to run on nodes with only a single executor to ensure that the situation doesn't arise. A real fix would be most helpful.

            Show
            m_broida m_broida added a comment - - edited Details on this workaround work, please? Does it prevent intentionally killing/aborting a build? Can a build step in the job just set a BUILD_ID envvar? Is the specific value "dontKillMe" required, or will any value work? Adding a parameter to every one of our many jobs (and new ones) would be a hassle, even if users could accept a default value. Can the BUILD_ID envvar be set in the overall Jenkins configuration to affect all Jenkins jobs? Can the BUILD_ID envvar be set at the OS level to affect all Jenkins jobs? We have had to restrict many of our jobs to run on nodes with only a single executor to ensure that the situation doesn't arise. A real fix would be most helpful.
            Hide
            chantivlad chanti vlad added a comment -

            @mdonohue: I think it does apply to enough users.

            Lots of us are using concurrent gmake builds without a problem on linux machines, and lots of us want to do just the same for msvc builds under windows.

            It would be definitely nice to have a checkbox for a "Windows Batch Command" build step or something like this, because a typical use case is not to kill mspdbsrv.exe for simultaneous visual studio builds.

            Show
            chantivlad chanti vlad added a comment - @mdonohue: I think it does apply to enough users. Lots of us are using concurrent gmake builds without a problem on linux machines, and lots of us want to do just the same for msvc builds under windows. It would be definitely nice to have a checkbox for a "Windows Batch Command" build step or something like this, because a typical use case is not to kill mspdbsrv.exe for simultaneous visual studio builds.
            Hide
            fnx Neil Bird added a comment -

            As it seems vaguely appropriate, I shall repeat here for interested parties what I've just commented on issue #9104 :

            Visual Studio is so ubiquitous that I personally think this could warrant a special case built into Jenkins, but anyway this is what we have just started doing (before calling devenv but after the MSC setup.bat has been called) to work around this (for all Windows builds):

            :: PITA to keep MSPDBSRV alive
            set ORIG_BUILD_ID=%BUILD_ID%
            set BUILD_ID=DoNotKillMe
            start mspdbsrv -start -spawn
            set BUILD_ID=%ORIG_BUILD_ID%
            set ORIG_BUILD_ID=

            It seems, from reading around, that the Jenkins process “tree” killer rummages through the whole process tree looking for processes with the environment variable BUILD_ID set to what Jenkins originally set it to, and killing any it finds. The above temporarily changes that to something else (anything, you could even just blank it), launches mspdbsrv manually (so it has the altered env. var.) and then puts it back (to restore the usual no-resource-leak fix).

            When you run mspdbsrv, it seems to immediately exit if there's already an appropriate version running, so it doesn't matter having multiple jobs trying to kick it off.

            Show
            fnx Neil Bird added a comment - As it seems vaguely appropriate, I shall repeat here for interested parties what I've just commented on issue #9104 : Visual Studio is so ubiquitous that I personally think this could warrant a special case built into Jenkins, but anyway this is what we have just started doing (before calling devenv but after the MSC setup.bat has been called) to work around this (for all Windows builds): :: PITA to keep MSPDBSRV alive set ORIG_BUILD_ID=%BUILD_ID% set BUILD_ID=DoNotKillMe start mspdbsrv -start -spawn set BUILD_ID=%ORIG_BUILD_ID% set ORIG_BUILD_ID= It seems, from reading around, that the Jenkins process “tree” killer rummages through the whole process tree looking for processes with the environment variable BUILD_ID set to what Jenkins originally set it to, and killing any it finds. The above temporarily changes that to something else (anything, you could even just blank it), launches mspdbsrv manually (so it has the altered env. var.) and then puts it back (to restore the usual no-resource-leak fix). When you run mspdbsrv, it seems to immediately exit if there's already an appropriate version running, so it doesn't matter having multiple jobs trying to kick it off.
            Hide
            oleg_nenashev Oleg Nenashev added a comment -

            The issue stills actual

            Show
            oleg_nenashev Oleg Nenashev added a comment - The issue stills actual
            Hide
            martinus Martin Ankerl added a comment - - edited

            Shorter version of the batch:

            cmd /c "set BUILD_ID=DoNotKill && start mspdbsrv -start -spawn -shutdowntime 2147483647"
            

            Update: Add -shutdowntime, see https://issues.jenkins-ci.org/browse/JENKINS-9104?focusedCommentId=162154&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-162154

            Show
            martinus Martin Ankerl added a comment - - edited Shorter version of the batch: cmd /c "set BUILD_ID=DoNotKill && start mspdbsrv -start -spawn -shutdowntime 2147483647" Update: Add -shutdowntime, see https://issues.jenkins-ci.org/browse/JENKINS-9104?focusedCommentId=162154&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-162154
            Hide
            alexey_larsky Alexey Larsky added a comment -

            I've try to use 'set BUILD_ID=DoNotKill && start mspdbsrv -start -spawn -shutdowntime 2147483647', but msbuild always starts your own instance of mspdbsrv with your BUILD_ID and kill it on finish build.

            Since Jenkins v 1.580.3 glovbal environment settings has been changed and for general node-wide disabling process killing you should add global environment variable 'BUILD_ID' with any value i.e. 'DoNotKill' and additional check 'Prepare jobs environment' checkbox. I don't found way to disable just mspdbsrv killing.

            Show
            alexey_larsky Alexey Larsky added a comment - I've try to use 'set BUILD_ID=DoNotKill && start mspdbsrv -start -spawn -shutdowntime 2147483647', but msbuild always starts your own instance of mspdbsrv with your BUILD_ID and kill it on finish build. Since Jenkins v 1.580.3 glovbal environment settings has been changed and for general node-wide disabling process killing you should add global environment variable 'BUILD_ID' with any value i.e. 'DoNotKill' and additional check 'Prepare jobs environment' checkbox. I don't found way to disable just mspdbsrv killing.
            Hide
            alexey_larsky Alexey Larsky added a comment -

            I really wonder why this issue priority is 'Trivial'. For me it's major.

            Show
            alexey_larsky Alexey Larsky added a comment - I really wonder why this issue priority is 'Trivial'. For me it's major.

              People

              • Assignee:
                Unassigned
                Reporter:
                olamy Olivier Lamy
              • Votes:
                13 Vote for this issue
                Watchers:
                15 Start watching this issue

                Dates

                • Created:
                  Updated: