Exec Stop Functionality in s6

[brutalgg]

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.

[skarnet]

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 down-signal file that allows you to configure the signal that is sent to your process in order to stop it.

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 foobar stop command actually react to signals, and what foobar stop does is simply look in the process table to find the instance of the foobard daemon, and send it a signal, often a SIGTERM. Use of that command is made totally unnecessary with a supervision system such as s6, because the supervisor already knows the pid of the process without having to look in the process table, and you simply have to tell it to send a signal - in which case the regular way of shutting it down, possibly with a custom down-signal, will work.

But yes, there are a few daemons that do not behave this way, and foobar stop uses other IPCs, in which case you have to use the daemon-specific command. For those, you need to first use s6-svc -O to tell the supervisor not to restart the process when it dies, then run your foobar stop command.

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.

[brutalgg]

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 SIGTERM signal does function and the server shuts down without data corruption however it does not capture the state of the game prior to shutdown. I've written custom tooling/shell script to shut down the server in a way where it saves before exiting.

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.

[skarnet]

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".

[ceache]

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> .

[skarnet]

s6-svscan's signal diversion is about the whole supervision tree, whereas OP's question was about a single service. It cannot help here.