-
Notifications
You must be signed in to change notification settings - Fork 33
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
Exec Stop Functionality in s6 #18
Comments
s6 does not provide that functionality, because it is basically impossible to implement without endangering the state machine of the supervisor and the stability of the system. (Obviously, that's something systemd does not care about.) The closest you can get is the It is a fundamental design flaw in a daemon if it cannot be cleanly stopped by a signal and needs a specific command. It goes against good practice on Unix systems. Fortunately, most daemons that come with a But yes, there are a few daemons that do not behave this way, and You seem to be using s6-overlay; I'm not sure exactly how the shutdown sequence is coded exactly, but there should be a way for you to invoke specific commands at shutdown time. If it's not the case, the only thing I can say is that a new version of s6-overlay is planned in a few months, and it will address your concern, among others. |
Thank you for this reply. I had went through all the documentation an expected this response however I figured I'd ask to have reference if anyone had a similar question in the future. The specific use case that I have relates to a game server. The You are correct that I'm using s6-overlay. The capability to execute code at shutdown does exist but the features in place appear to be after a signal is sent. I.E final is meant to do memory or filesystem cleanup. Either way this functionality covers an arguably limited use case that can be worked around so I understand the exclusion. Thanks again. |
If you have access to the game server's upstream, you could suggest them to devote a signal to the "save the game state then exit" action, which is a common thing that administrators would reasonably want to do. I would even argue that this should be the default behaviour for a |
Would using s6-svscan signal diversion not help?
Setup a SIGUSR1 (for example) handler that calls your custom script and use
"docker kill --signal=SIGUSR1" to trigger the graceful shutdown vs docker
stop to have the regular one.
I am unsure if such a setup is supported by s6-overlay though...
Just a thought
…On Wed, Sep 16, 2020, 10:45 Laurent Bercot ***@***.***> wrote:
If you have access to the game server's upstream, you could suggest them
to devote a signal to the "save the game state then exit" action, which is
a common thing that administrators would reasonably want to do. I would
even argue that this should be the default behaviour for a SIGTERM, and
that the server should have another signal (for instance SIGQUIT) that
means "exit without saving the state".
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#18 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAIFTHQI5OJDLC2OVJ3IND3SGDFRXANCNFSM4RN6ISTQ>
.
|
|
I've just started using s6 in some containers and I'm trying to identify a way to replicate the functionality of ExecStop in systemd? Essentially i would like to send a specific command to shutdown a process. I've attempted to use the final service file functionality as well as cont-final.d and down-signal but neither of those locations seem to execute prior to the SIGTERM being sent. Assistance is greatly appreciated.
The text was updated successfully, but these errors were encountered: