Re: possible to transform signals sent by s6-svc?

2016-10-23 Thread Brett Neumeier
On Sat, Oct 15, 2016 at 12:09 AM, Laurent Bercot <
ska-supervis...@skarnet.org> wrote:

> 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.
>>
>
> The problem with custom control is [...]

A bad script could make s6-supervise unresponsive and
> useless. I thought it was too much of a risk for the benefit it brings.
>

(Hunh, I tried sending this almost a week ago and it bounced. Strange.)

I concur. And it's not particularly important, as far as that goes -- as
you pointed out, using -Oic is arguably the right thing to do, because it's
more transparent about what is going on. The only reason I prefer "-d" is
that it's more symmetric with other managed services, and if the database
needs to be bounced in a hurry it's likely because of a crisis, and I hate
to increase the cognitive load on the operator who's trying to deal with
the hypothetical future crisis.

On the other hand, I can write a *really simple* control script that just
takes sysvinit-style "start," "stop", "reload" etc arguments and runs the
appropriate s6-svc command. Or, alternatively:

 But there's a way to trap and convert signals in your run script itself:
>  http://skarnet.org/software/execline/trap.html


I had totally missed the trap command! That provides a nice workaround.
Thank you! I'll try modifying the run script to use this approach and see
whether the result makes me happier than the control-script approach.

Cheers,

Brett


-- 
Brett Neumeier (bneume...@gmail.com)


Re: possible to transform signals sent by s6-svc?

2016-10-17 Thread Martin "eto" Misuth
On Sat, 15 Oct 2016 05:09:16 +
"Laurent Bercot"  wrote:
> >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.

I've hit this occasionally, but it's not a big deal, as most daemons do "right
thing" when getting SIGTERM.

However if you ever plan to do this, I would like to suggest what I personally
would like best: using same file "interface" as with ./timeout-finish.

This would make it easy to spot special "outlier" services which are not like 
the rest.

  eto


Re: possible to transform signals sent by s6-svc?

2016-10-14 Thread Laurent Bercot
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



possible to transform signals sent by s6-svc?

2016-10-14 Thread Brett Neumeier
I'm starting to use s6 to manage long-running processes on my servers -- so
far, with great success. One of these services is PostgreSQL.

PostgreSQL can be terminated gracefully by sending it SIGTERM, SIGINT, or
SIGQUIT. Each is handled differently: with TERM, the server waits for all
sessions to disconnect before it shuts down the database; with INT, it
forcefully disconnects all current sessions and then shuts down the
database; and with QUIT, it terminates the database without doing a
checkpoint and graceful shutdown at all.

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

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!

Cheers,

Brett

-- 
Brett Neumeier (bneume...@gmail.com)