Re: Generic interrupt command?

["John O'Meara" <john.fr.omeara@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1974 bytes --]

On Tue, Feb 5, 2019, 2:30 PM Laurent Bercot <ska-supervision@skarnet.org
wrote:

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

>