-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OME docker container doesn't respond to SIGTERM #1531
Comments
For those who use docker-compose, put this into your docker-compose.yml as a workaround: |
Is this why a docker-compose down takes so long with OME? I figured it was cleaning up, but maybe it's timing out and is forcibly killed? |
@naanlizard yes, it is. By default Docker will wait 10 seconds and then kill the service. |
This was something we overlooked. I've updated the |
SIGKILL doesn't allow for any graceful shutdown, though. I imagine it can be very bad for stream recording, for example. Does OME support graceful shutdown? |
I am also rather concerned about recordings and would like to know more |
@d-uzlov To elaborate further, during the initial development of the OME, I had implemented graceful shutdown upon receiving the If I have more time to focus on OME, I'll support |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Describe the bug
SIGTERM is the standard way for a graceful program termination.
The official OME container doesn't seem to respond to it.
It does seem to correctly shut down on SIGABRT (well, at least there is a log entry, so I guess it must be graceful shutdown and not a default handler) but docker and k8s both use SIGTERM as the default shutdown signal.
To Reproduce
As you can see,
docker kill --signal SIGTERM ome
did nothing, anddocker stop ome
hanged until 10s timeout.Expected behavior
Container performs graceful shutdown on SIGTERM.
Server:
docker.io/airensoft/ovenmediaengine:0.16.4
Additional context
I don't have a server with non-docker OME available, so I can't check if this is a docker-specific issue. If it is, then my guess is that it may be related to linux disabling default signal handlers for PID 1.
Also, as a sanity check, here is a similar test with nginx:
The text was updated successfully, but these errors were encountered: