>So what I'd like to do is have "s6-svc -d" result in the process
>receiving
>SIGINT and SIGCONT to the supervised process, rather than SIGTERM and
>SIGCONT.
>
>It doesn't seem like there's a way to do this. Or am I missing
>something?
No, you can't remap s6-svc -d. This is a feature that runit has and s6
doesn't: if it's important to you, runit can do it.
The problem with custom control is that unlike runsv, s6-supervise is
implemented as a full DFA over an asynchronous loop (which is a good
thing, because it guarantees consistency of state and responsiveness),
and
spawning a user-controlled customized control script would completely
mess
with the design. A bad script could make s6-supervise unresponsive and
useless. I thought it was too much of a risk for the benefit it brings.
As you found out, s6-svc -Oic is the way to down the service with a
SIGINT
(and a SIGCONT for safety).
>It looks like there is a mechanism to do that kind of signal remapping
>in
>s6-svscan, using the -s option, but the documentation for servicedirs
>doesn't mention anything like that.
It's different for s6-svscan, because spawning the custom signal
handlers
for s6-svscan does not mess with its internal state. If the custom
signal
handlers do something crazy like stalling forever, s6-svscan is still
responsive and performing its job. That's not possible with
s6-supervise,
unfortunately.
>If I'm right and there's no easy way to do that, it's not necessarily a
>huge problem -- currently I'm just using "s6-svc -iO" to shut down
>PostgreSQL, and I can keep doing that; or, alternatively, I can patch
>PostgreSQL to switch the behavior of TERM and INT. But if there *is* a
>way
>to get s6-svc to behave differently, I'm interested!
s6-svc, no - at least not yet. Apparently there's some demand for that
functionality, so I'll probably think about a way to implement it
safely,
in a future version of s6.
But there's a way to trap and convert signals in your run script
itself:
http://skarnet.org/software/execline/trap.html
If your run script is written in shell, you can achieve more or less
the
same effect with a script akin to the one described here:
https://github.com/just-containers/s6-overlay/issues/41#issuecomment-97342699
(this is the very discussion that led me to write the "trap" execline
command).
It's a dirty workaround, it uses one more process, but what can you do
when daemons don't use SIGTERM as you would want them to. :)
For PostgreSQL, though, the semantics are arguably correct: SIGTERM for
a really clean shutdown and SIGINT for a forced (but still clean)
shutdown; you just don't want to wait for all client sessions to
disconnect,
so you use a different s6-svc command. Seems to me like everything is
working as intended. :)
--
Laurent
Received on Sat Oct 15 2016 - 05:09:16 UTC