>That's a tough call. On the one hand, it makes simple constructs safer.
>On the other, it adds complexity to interpreting the data
>programmatically ( the test / [ program errors for integer comparisons
>with text, and using scanf() to pull in the values for libc style
>programs wouldn't be so simple anymore).
That was my thought process originally, but if it makes it riskier
or more annoying for programs to use the result of s6-svstat,
especially in scripts which are its likely users, I'm willing to
change that.
>Also, while thinking about this, I wonder the risk of signaling the
>wrong program. When svc does it via supervise, it can know the right
>program gets the signal because it handles the cleaning of the child
>PID. In a script, there is a chance the child has exited and been
>replaced between the time the PID was queried by svstat and the time
>the kill command gets executed. I don't know how likely a new program
>might get the old PID in that time, this receiving the signal intended
>for the original child.
Well that is one of the reasons for using a supervisor in the first
place. Only the parent of a process can reliably send signals to it.
Any time you're trying to signal a program and you're not a parent,
you are subject to that risk condition. The only 100% safe way is
using s6-svc, there's no changing that.
So far the only real need to customize a signal has been for the
signal that brings a service down, which is now achieved via
./down-signal. I haven't been told of any real use case where
sending a non-supported signal, without intending to terminate the
service, was necessary.
--
Laurent
Received on Sun Feb 10 2019 - 11:41:19 UTC