Answers: <p>You are running into a conflict between jenkins nature of making sure everything is done before a job is complete and your desire for some long-running things to be asynchronous.  There is no right answer here, both are reasonable desires, but you and jenkins are pulling in different directions.  It may be ok for some parts of the jenkins job to not be completely done but they are good enough for the job.  This is a decision you get to make.</p>
  
  <p>If getting this working inside of jenkins is too much trouble there are work arounds.  You can make your own daemon that looks for job completions (via files or database entries) and then starts something else.  Obviously this means you lose the UX features of jenkins that let everybody know where something is.  But you could make this work inside of jenkins by having different jobs also.  The quick job finishes and then the longer job takes over.  Since each is its own job it can have timeout requirements that make sense for it.</p>
  
Answers: CC BY-SA 4.0
Answers: 2018-10-30T06:44:04.497Z
Answers: Thanks! A quick question to clarify my understandings of your response: by *The quick job finishes and then the longer job takes over. Since each is its own job it can have timeout requirements that make sense for it.* do you mean: 
  
  1. The **upstream** job builds then triggers the **downstream** job to start the server 
  2. Set timeout for **downstream** job, so it will terminate (and kill server) and shows that the job has finished on Jenkins
Answers: Tran Triet
Answers: CC BY-SA 4.0
Answers: 2018-10-30T09:39:42.000Z
Answers: Yep, it sounds like you understand.  I'm not great at using the jenkins-correct term for things.
Answers: chicks
Answers: CC BY-SA 4.0
Answers: 2018-10-30T13:43:18.843Z
Answers: Sorry, I didn't mean to correct your choice of words or anything (I'm a newbie to this myself) I just want to confirm my understanding so I don't misunderstand your response. Thanks again for the answer.
Answers: Tran Triet
Answers: CC BY-SA 4.0
Answers: 2018-10-28T13:09:19.373Z
Answers: 2018-10-28T13:09:19.373Z
Answers: chicks
Body: <p>I want the Jenkins agent to <strong>build</strong> and <strong>start</strong> the server.</p>
  
  <p>I do this by specifying how to build and start the server in the <em>Build</em> step of the project configuration in <strong>Bash</strong></p>
  
  <pre><code>echo "Installing dependencies"
  npm install
  echo "Starting server"
  ./startscript.sh 3000 &amp; #this script will start the server with specified port
  </code></pre>
  
  <p><strong>Why the ampsersand in <code>/startscript.sh 3000 &amp;</code>?</strong></p>
  
  <p>I noticed that without the ampersand <code>&amp;</code> in the last command, the server is started as expected (I can access it from browser). However, the Jenkins build hangs and cannot finish (because the script starts the server and won't return until the server is terminated).</p>
  
  <p>So I tried to fix this with adding the ampersand to make the script process runs in background. With this, Jenkins job successfully ends the build.</p>
  
  <p><strong>But adding the ampersand still doesn't fix</strong>
  The server process is still terminated (it actually started because I checked the log and saw that it was started). I think that this might be because when Jenkins finishes building, it exits the shell and sends the <strong>SIGHUP</strong> to attached background jobs.</p>
  
  <p><strong>Adding nohub still doesn't fix</strong></p>
  
  <p>Running the last command with <code>nohup ./startscript.sh 3000 &amp;</code> still doesn't fix the bug.</p>
  
  <p><strong>Question</strong></p>
  
  <p>How to make the agent build then start the server.</p>
  
  <p><strong>Note</strong></p>
  
  <p>The console output of Jenkins builds shows both the command and the output of it (like the behaviour of the -x flag of the shell). And the last command was shown like this:</p>
  
  <pre><code>+ nohup ./startscript.sh 3000
  Finished: SUCCESS
  </code></pre>
  
  <p>It doesn't show the ampersand <code>&amp;</code>... So I don't know if the ampersand was actually correctly interpreted during the run.</p>
  
Tags: <jenkins><builds><bash>
Title: How to make the Jenkins agent build then start the server?
UserDisplayName: Tran Triet
ThreadText: # How to make the Jenkins agent build then start the server?
  
  (Asked by: username_0 on 2018-10-28)
  
  I want the Jenkins agent to **build** and **start** the server.
  
  I do this by specifying how to build and start the server in the *Build* step of the project configuration in **Bash**
  
  ```
  echo "Installing dependencies"
  npm install
  echo "Starting server"
  ./startscript.sh 3000 & #this script will start the server with specified port
  
  ```
  
  **Why the ampsersand in `/startscript.sh 3000 &`?**
  
  I noticed that without the ampersand `&` in the last command, the server is started as expected (I can access it from browser). However, the Jenkins build hangs and cannot finish (because the script starts the server and won't return until the server is terminated).
  
  So I tried to fix this with adding the ampersand to make the script process runs in background. With this, Jenkins job successfully ends the build.
  
  **But adding the ampersand still doesn't fix**
  The server process is still terminated (it actually started because I checked the log and saw that it was started). I think that this might be because when Jenkins finishes building, it exits the shell and sends the **SIGHUP** to attached background jobs.
  
  **Adding nohub still doesn't fix**
  
  Running the last command with `nohup ./startscript.sh 3000 &` still doesn't fix the bug.
  
  **Question**
  
  How to make the agent build then start the server.
  
  **Note**
  
  The console output of Jenkins builds shows both the command and the output of it (like the behaviour of the -x flag of the shell). And the last command was shown like this:
  
  ```
  + nohup ./startscript.sh 3000
  Finished: SUCCESS
  
  ```
  
  It doesn't show the ampersand `&`... So I don't know if the ampersand was actually correctly interpreted during the run.
  
  **Tags:** jenkins, builds, bash
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2018-10-28. Score: 3 | Accepted answer
  
  You are running into a conflict between jenkins nature of making sure everything is done before a job is complete and your desire for some long-running things to be asynchronous. There is no right answer here, both are reasonable desires, but you and jenkins are pulling in different directions. It may be ok for some parts of the jenkins job to not be completely done but they are good enough for the job. This is a decision you get to make.
  
  If getting this working inside of jenkins is too much trouble there are work arounds. You can make your own daemon that looks for job completions (via files or database entries) and then starts something else. Obviously this means you lose the UX features of jenkins that let everybody know where something is. But you could make this work inside of jenkins by having different jobs also. The quick job finishes and then the longer job takes over. Since each is its own job it can have timeout requirements that make sense for it.
  
  > **Comments:**
  > **username_0**: Thanks! A quick question to clarify my understandings of your response: by *The quick job finishes and then the longer job takes over. Since each is its own job it can have timeout requirements that make sense for it.* do you mean:   1. The **upstream** job builds then triggers the **downstream** job to start the server  2. Set timeout for **downstream** job, so it will terminate (and kill server) and shows that the job has finished on Jenkins  
  > **username_1**: Yep, it sounds like you understand.  I'm not great at using the jenkins-correct term for things.  
  > **username_0**: Sorry, I didn't mean to correct your choice of words or anything (I'm a newbie to this myself) I just want to confirm my understanding so I don't misunderstand your response. Thanks again for the answer.  
  
  ---
  
  