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
