1

This is the code:

description "NZBGet upstart script"

setuid martin
setgid martin

start on runlevel [2345]
stop on runlevel [016]

respawn

pre-start script
exec /home/martin/nzbget/nzbget -D
end script

pre-stop script
exec /home/martin/nzbget/nzbget -Q
end script 

Program starts fine. However, it never seems to stop. sudo service nzbget stop indicates nzbget stopping/waiting but the line exec /home/martin/nzbget/nzbget -Q never appears to get executed. Any ideas how to fix this problem?

3
  • Your configuration is weird. Where's the actual service command( (a simple script block or exec line? Why is there a respawn line when there is nothing to respawn?
    – muru
    Sep 15, 2015 at 4:46
  • I thought was respawn was in case the program crashed. Will respawn not execute pre and post scripts? I see your point about the script not spawning any processes. I tried removing pre-start condition but then it just doesn't work. Sep 15, 2015 at 22:20
  • with nothing in a script or exec block, how can Upstart know what process belonged to the daemon proper? Processes stated by pre-start/post-stop blocks aren't tracked by Upstart.
    – muru
    Sep 15, 2015 at 22:24

1 Answer 1

1

Edit-Thanks to muru this is a working solution.

description "NZBGet upstart script"

setuid {user}
setgid {group}

start on runlevel [2345]
stop on runlevel [016]

respawn
respawn limit 5 30
expect fork

exec /home/{user}/nzbget/nzbget --daemon
# post-start /home/{user}/nzbget/nzbget --{user-defined configuration options}
5
  • If your program has a daemon mode, then that command should be in exec not in pre-start.
    – muru
    Sep 15, 2015 at 22:25
  • If I did that, then nzbget would not quit. Believe me I've tried. I get 'stop: unknown instance' error. It starts but the the only way to stop it, is through the application itself or doing ps aux, finding the process ID and killing it that way. The reason is, once the program starts, upstart thinks it's already in a stopped/waiting status. This is why pre-start script was added which is not ideal because then it loses the PID. Sep 15, 2015 at 23:27
  • Believe me, trying in the wrong ways isn't of much use. If the daemon starts and forks off into the background, Upstart needs to be told that using the expect setting. I'd guess you need expect fork, but you'll have to experiment to figure out.
    – muru
    Sep 15, 2015 at 23:34
  • Huh, expect fork actually made it all work. Thank you so much. I'll update this post in case someone else gets stuck. Sep 15, 2015 at 23:54
  • given the update, the post-stop line is irrelevant - by the time it is executed, the process should already have stopped.
    – muru
    Sep 16, 2015 at 0:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .