[JIRA] (JENKINS-61950) Environment variables with '$' have '$$' when used in sh step inside a container step.

[kerog...@cloudbees.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kenneth Rogers created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-61950  
 
 
  Environment variables with '$' have '$$' when used in sh step inside a container step.   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 kubernetes-plugin  
 
 
Created: 
 2020-04-17 14:49  
 
 
Environment: 
 CloudBees Core 2.222.1.1, Kubernetes plugin 1.25.2  
 
 
Labels: 
 kubernetes-plugin  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 Kenneth Rogers  
 

  
 
 
 
 

 
 Here's a pipeline that reproduces the bug:   

 

podTemplate {
  node(POD_LABEL) {
container("jnlp") {
  stage("Run") {
env.FOO = '$string\$with\$dollars'
echo "from groovy: ${env.FOO}"
sh 'env | grep FOO'
sh 'echo from sh: $FOO'
}
 }
  }
}
 

 Here's the output: from groovy: $string$with$dollars FOO=$$string$$with$$dollars from sh: $$string$$with$$dollars Note that all the dollar signs have been doubled! Note that we've included a call to env, which prints the same incorrect string, so that we can eliminate the possibility of groovy string interpolation issues. We isolated the problem to the container() function. The bug does not occur with this version of the code, where it is removed, despite that the exact same container (jnlp) is actually used:   

[JIRA] (JENKINS-58656) Wrapper process leaves zombie when no init process present

[kerog...@cloudbees.com (JIRA)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Kenneth Rogers commented on  JENKINS-58656  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Wrapper process leaves zombie when no init process present   
 

  
 
 
 
 

 
 I have been unable to reproduce the `Resource temporarily unavailable.` error when attempting to run pipelines that simulate the situation described. I created a cluster in GKE using the gcloud cli. gcloud container clusters create  --machine-type=n1-standard-2 --cluster-version=latest. Installed Cloudbees Core for Modern Platforms version 2.204.3.7 (latest public release at the time I started testing) using Helm. Used kubectl get nodes to find the names of the nodes and gcloud beta compute ssh to connect to the nodes via ssh. Then running watch 'ps fauxwww | fgrep Z' to watch for zombie processes on each node. Using groovy while (true) { sh 'sleep 1' } I was able to produce zombie processes on the node the build agent was assigned to. The process ran for 5 hours 17 minutes before using all the process resources. After the processes were exhausted the job exited with an error message that there were not processes available. After the pod running the job exited the zombie processes on the node were removed and the node continued to function. Using `while :; do /usr/bin/sleep .01; done` as a way to generate subprocesses I've tested as the direct parameter of an `sh` step in a pipeline using both `jenkins/jnlp-slave` and `cloudbees/cloudbees-core-agent` images. Neither produced any zombie processes on the worker nodes of the Kubernetes cluster. To induce another layer of subprocess I also put that `while` line into a file and had the `sh` process execute that file, but it also did not produce any zombie processes on the worker nodes. Additionally I made that while loop a step in a Makefile and executed it that way, which also did not produce any zombies on the nodes.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)