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.


How to make the agent build then start the server.


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.

1 Answer 1


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.

  • 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
    – Tran Triet
    Commented Oct 30, 2018 at 6:44
  • Yep, it sounds like you understand. I'm not great at using the jenkins-correct term for things.
    – chicks
    Commented Oct 30, 2018 at 9:39
  • 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.
    – Tran Triet
    Commented Oct 30, 2018 at 13:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.