You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
docker/podman stop script-server sends first SIGTERM, then, after a timeout, SIGKILL.
script-server seems to ignore SIGTERM, so docker/podman sends SIGKILL after the timeout.
I see that ./src/web/server.py/intercept_stop_when_running_scripts() configures a handler for SIGINT that will do a clean shutdown as long as there are no currently-running scripts.
Would it be possible to do a clean shutdown on SIGTERM also? It could be like the existing behaviour for SIGINT except (I guess) acting as though the user answered n to the question Do you want to stop server anyway?.
The text was updated successfully, but these errors were encountered:
Hi @rwalkerands, thanks for reporting. I'm not sure what is the problem. In my understanding, SIGINT is needed for script server only to ask confirmation from a user.
If such confirmation is not needed, a signal (SIGTERM) should be propagated to all children processes. So that it's the responsibility of the children processes to handle SIGTERM properly.
Could you confirm, that if there are no running scripts, Script server stops on SIGTERM? Or you mean, that even in this case, SIGTERM is ignored?
docker/podman stop script-server
sends firstSIGTERM
, then, after a timeout,SIGKILL
.script-server
seems to ignoreSIGTERM
, sodocker/podman
sends SIGKILL after the timeout.I see that
./src/web/server.py/intercept_stop_when_running_scripts()
configures a handler for SIGINT that will do a clean shutdown as long as there are no currently-running scripts.Would it be possible to do a clean shutdown on SIGTERM also? It could be like the existing behaviour for SIGINT except (I guess) acting as though the user answered
n
to the questionDo you want to stop server anyway?
.The text was updated successfully, but these errors were encountered: