tini doesn't like if SIGTERM in a child takes some time about tini HOT 3 CLOSED

No, Tini does not make any assumptions about the meaning of the signal it receives and simply forwards it to its child.

The only signal-specific handling in Tini is a set of signals that are not passed on to its child:

It's most likely that Bash is the one with signal-specific handling here: when Tini proxies SIGTERM to its child, that child is Bash, and Bash decides what to do with the signal. In this case, it looks like it's respectively proxying SIGINT to your Python script and exiting immediately upon SIGTERM.

The best approach here would be to remove the middleman (Bash) when you no longer need it. Assuming spinning up your Python web server is the last thing you do in your Bash script, this is trivial.

Just rewrite sig_bash.sh as is:

#!/bin/bash

# Whatever set up you have already
do one thing
do another thing

# The exec part is what matters here
exec python sig_handle.py

Here, using exec means "replace my Bash shell with Python". This does mean you cannot run anything in the Bash script after you call exec, but that's probably OK since your Python script is presumably able to cleanup after itself in its own signal handlers.

Now, the effect of using exec here is that, you'll have a process hierarchy that looks like Tini -> Python as opposed to Tini -> Bash -> Python, so when Tini proxies a signal to its child, that's no longer Bash: it's your Python process. This means your Python script will receive signals directly, and will be free to handle them however it sees fit.

See #72 for essentially the same issue.

Cheers,

from tini.

Gah, I looked for a duplicate issue and couldn't find one! Sorry about that.

But thank you very much for the explanation. You're spot on, it was the way bash handled SIGTERM. Your suggestion worked great. Not only did it fix my problem, but I learned the behavior of bash exec in the process!

from tini.

Gah, I looked for a duplicate issue and couldn't find one! Sorry about that.

No problem :)

But thank you very much for the explanation. You're spot on, it was the way bash handled SIGTERM. Your suggestion worked great. Not only did it fix my problem, but I learned the behavior of bash exec in the process!

Happy to help!

from tini.