I'm seeing some unexpected behavior with runit and not sure how to get it to do what I want without throwing an error during termination. I have a process that sometimes knows it should stop itself and not let itself be restarted (thus should call sv d
on itself). This works if I never change the user but produces errors if I switch to a non-root user when running.
I'll use the same finish
script for both examples:
#!/bin/bash -e
echo "downtest finished with exit code $1 and exit status $2"
The run
script that works as expected (prints downtest finished with exit code 0 and exit status 0
to syslog):
#!/bin/bash -e
exec 2>&1
echo "running downtest"
sv d downtest
exit 0
The run
script that doesn't work as expected (prints downtest finished with exit code -1 and exit status 15
to syslog):
#!/bin/bash -e
exec 2>&1
echo "running downtest"
chpst -u ubuntu sudo sv d downtest
exit 0
I get the same result if I use su ubuntu
instead of chpst
.
Any ideas on why I see this behavior and how to fix it so calling sudo sv d downtest
results in a clean process exit rather than returning error status codes?
sv d
sends a SIGTERM if the process is still running. This is signal 15, hence the error being handled in the manner in question.
By contrast, to tell a running program not to start up again after it exits on its own (thus allowing that opportunity), use sv o
(once
) instead.
Alternately, you can trap SIGTERM in your script when you're expecting it:
trap 'exit 0' TERM
If you want to make this conditional:
trap 'if [[ $ignore_sigterm ]]; then exit 0; fi' TERM
...and then run
ignore_sigterm=1
before triggering sv d
.