On Tue, Feb 5, 2019, 2:30 PM Laurent Bercot >Not outputting anything causes kill (on my system at least) to exit non > >0 > > Not outputting anything isn't an option, for the case where -o pid is > used in addition to other fields. The field number and order must be > respected. > Agreed; I didn't mean to suggest that as an option, I just wanted to be thorough with testing. It's probably best to use some OOB indicator. How about NA, which I > already use for non-numeric fields? it makes kill correctly choke. > Would it be better to use NA in all the numeric fields, too? > 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). Maybe adding a flag like -n as an output modifier to keep the relevant output numeric when wanted? Then the default could be NA. Of course, that adds complexity to the svstat program, it's interface and documentation. It is also incompatible with existing programs that may be using svstat already, requiring the flag for new versions of svstat and not the flag for old versions. 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. I think itis a low number, but not zero. This line of thinking unfortunately brings us back to the original post in this thread :-( -- John O'Meara >