Hi Thorsten,
This is Pipeline working as designed – what you're describing would permit the Pipeline to leak processes potentially due to how it's launching them with the shell step. IIUC what you're saying, the fact that it doesn't kill the process in FreeStyle projects would be a bug with Freestyle.

Hi svanoort,

this is either a bug for FreeStyle projects and therefore also a bug in the documentation, because the documentation page of the ProcessTreeKiller @ https://wiki.jenkins.io/display/JENKINS/ProcessTreeKiller clearly states what you should do when you want to keep a Daemon process alive. Or this is working as intended for FreeStyle projects but is broken for Pipeline builds.

Besides there are very good reasons for keeping a process running. E.g. when you are using Gradle for your build environment, Gradle starts a Daemon that make subsequent builds faster. As Jenkins kills all Daemons at the end of each build, it clearly breaks a feature of Gradle. So there have to be a possibility to keep created processes alive.

oleg_nenashev or jglick maybe one of you can comment on this.

Thanks in advance!

Generally I agree with your diagnosis gfriedrich. The feature is documented in a way that it makes impression that it should work in Pipeline. Just because there was no Pipeline in April 2011 when the page was updated last time...

"dont-kill-me" always seemed to be a hack to me. If there are processes which should not be terminated by builds, they should be ideally to be started in another way (e.g. by service, etc.). In the case of Gradlethe daemon could be started automatically outside the Jenkins job (e.g. by VM initialization logic or by a Gradle tool installer).

• If Durable Task logic does not support ProcessTreeKiller extension points, this is a bug.
• If it just does not support "dont-kill-me", I think it would be enough to document it.

It would be a real shame if this very useful functionality wasn't available in Pipeline jobs. We use it to deploy the full application stack after a build which can then be used for testing and playing around. Since we have many branches it's not feasible to set up environments outside of Jenkins and somehow deploy the build results.

I think so too, oleg_nenashev. Overriding the BUILD_ID environment variable looks very hacky.

Unfortunately there is no possibility for Gradle to run the daemons initially. And of course the daemon feature of Gradle will only make sense for "always-on" build nodes, so using it in combination with docker agents is useless.

That said: Would it be possible (from an architectural point of view) to disable the ProcessTreeKiller for specific builds instead of using this BUILD_ID hack? I think there are enough reasons here to give users the possibility to do so.