Re: Generic interrupt command?

["Laurent Bercot" <ska-supervision@skarnet.org>]

>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