I wrote an upstart script to launch a daemon inside a tmux session. It works well and respawns the process if it dies unexpectedly, but I can't seem to stop it manually.

The job (called bukkit) looks like this:

start on filesystem
stop on runlevel [!2345]

respawn limit 5 30

chdir /home/minecraft/bukkit

expect daemon
kill timeout 30

pre-start script
    test -x /home/minecraft/bukkit/craftbukkit-0.0.1-SNAPSHOT.jar || { stop; exit 0; }
end script

pre-stop script
    tmux send -t bukkit "stop"
    tmux send -t bukkit "Enter"
    sleep 10  # Wait for server to shut down properly
end script

exec tmux new-session -d -s minecraft -n bukkit "sudo -u minecraft -- /home/minecraft/java/jre1.6.0_27/bin/java -Xincgc -Xmx1G -jar /home/minecraft/bukkit/craftbukkit-0.0.1-SNAPSHOT.jar"

When I issue a stop bukkit it freezes for ~10 seconds (the sleep timer, I guess) and prints bukkit start/running, process 2391. When I set upstart to debug, I found these relevant lines in the log:

Sep 21 19:14:59 cheftest init: bukkit goal changed from start to stop
Sep 21 19:14:59 cheftest init: bukkit main process (2499) exited normally
Sep 21 19:14:59 cheftest init: bukkit main process ended, respawning
Sep 21 19:14:59 cheftest init: bukkit goal changed from stop to respawn

Why does upstart keep respawning my process when it is supposed to stop it?


The difficulty here is the combination of 'respawn' with a pre-stop script that tells the process to stop. From init(5):

         A service or task with this stanza will be automatically started
         if it should stop abnormally.  All reasons for a service stopping,
         except the stop(8) command itself, are considered abnormal.  Tasks
         may exit with a zero exit status to prevent being respawned.

The documentation is a little unclear on the point of whether exiting with a zero exit status should cause a respawn. However, fundamentally you've found an upstart bug because the main process ending when the goal is 'stop' should not result in a change to 'respawn'.

To work around this bug, you should be able to use "normal exit" to tell upstart that this is a normal way to stop the job and that it should not respawn.

  normal exit STATUS|SIGNAL...
         Additional exit statuses or even signals may be added, if the
         job process terminates with any of these it will not be considered
         to have failed and will not be respawned.

         normal exit 0 1 TERM HUP

Note that in general, it would be more robust to kill the process with a signal (specifying "kill signal N" if necessary) instead of with a pre-stop process that issues commands; but of course this is not always possible if the service doesn't support clean shutdown upon receipt of a signal.

  • Thank you, that work-around works perfectly for my case. I found a bug report for this, but it seems that this behavior is actually consciously designed. – passy Sep 22 '11 at 8:32
  • Scott James Remnant's answer there is the correct one - it is a bug, not a design decision, the test case referred to is meant to test something else :) – slangasek Sep 28 '11 at 5:19

In case anyone else ends up here I've submitted a working patch to the bug:


  • Welcome to Ask Ubuntu! Whilst this may theoretically answer the question, it would be preferable to include the essential parts of the answer here, and provide the link for reference. – Peachy Nov 20 '12 at 22:07

A fix was released in upstart 1.10 for this, so now it shouldn't happen.

  • This does not provide an answer to the question. To critique or request clarification from an author, leave a comment below their post. – amc May 18 '14 at 2:57
  • 2
    I'm not completely sure of that. My answer is equivalent to saying: It happens because you're using an old version of upstart which had a bug, use version 1.10 or newer to fix it. Something that none of the other answers state, and actually the most useful answer now that the fix has been released and there is little reason for a workaround. – cprcrack May 18 '14 at 9:59
  • I agree it's useful but I think it's more useful as a comment to the accepted answer – amc May 18 '14 at 16:34

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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