Re: machine api to supervise

[Buck Evan]

If you'll specify how you want it to look / work I'll (possibly) attempt to
provide a patch.

`s6-svstat --json` is my initial bid.

I'll try to match the nosh output as closely as is reasonable.

On Thu, Sep 24, 2015 at 4:27 AM, Laurent Bercot  wrote:

> On 24/09/2015 12:56, e-mail j.deboynepollard-newsgroups wrote:
>
>>  Unless some daemontools-family
>> developer goes and does something wrongheaded like breaking compatibility
>>
>
>  I did. There were good reasons for it: the way the bits are arranged in
> the legacy daemontools status format is suboptimal, and getting the useful
> information out of it requires a little extra work - and I got confused
> a few times by the meaning of the bits.
>
>  The status file was never an "official" interface, and the tools that
> parse it are actually looking under the hood and breaking abstraction
> layers. I'm surprised that you, of all people, advocate this procedure:
> this is clearly bad programming practice.
>
>
> There is something wrong with processing the output of svstat, and you are
>> right to be leery of doing so. The daemontools manual explicitly states
>> that it
>> is human readable, rather than machine-readable. And there are variations
>> in the
>> human-readable forms, which are fine for humans but no good for programs.
>>
>
>  Still, svstat is the only "official" interface, so for now it's the only
> safe way to proceed. I agree that it is inconvenient, and that daemontools
> should have provided a tool to get machine-readable status information;
> but in the absence of such a tool, svstat is the entry point and should
> be used as such.
>
>  s6 provides a C API to read status: s6_svstatus_read(). The command-line
> interface to it is s6-svstat. It's currently lacking options to output
> machine-readable data; I plan to add that functionality, but in the
> meantime, it *is* the interface.
>
> --
>  Laurent
>
>

Re: machine api to supervise

[Avery Payne]

It would be nice to develop a common "grammar" that describes whatever 
is being probed.  If the grammar was universal enough, you could fill in 
empty strings or zeros for things that don't apply, but the interpreter 
for the state data need only be written once.


The following pipe-dream passes for valid json according to 
http://jsoneditoronline.org but some of the data might not even be 
available, so a lot of it is just wishful thinking...


{
  "servicelist": {
"myservice":
{
  "definition":
  {
"type": "s6",
"path": "/path/to/service/definition",
"run": "myservice"
  },
  "state":
  {
"uptime": "54321 seconds",
"last-start": "2015-10-16 18:27:32 PST",
"last-state": "unknown",
"number-restarts": 0,
"wanted": "up",
"currently": "up"
  },
  "env-vars":
  {
"A_STRAY_ENV_VARIABLE": "option-blarg",
"DAEMONSETTING": "--some-daemon-setting",
"OTHEROPTION": "myobscureoptionhere",
"PATH": "/sbin:/usr/sbin:/bin:/usr/bin:/path/to/service/definition"
  },
  "supervisor":
  {
"name": "s6-supervise",
"pid": 123,
"uid": 0,
"gid": 0,
"stdin": 0,
"stdout": 1,
"stderr": 1
  },
  "daemon":
  {
"name": "my-service-daemon",
"pid": 124,
"uid": 101,
"gid": 102,
"stdin": 0,
"stdout": 1,
"stderr": 1
  },
  "logger":
  {
"name": "logwriterprocess",
"pid": 125,
"uid": 99,
"gid": 999,
"stdin": 0,
"stdout": 1,
"stderr": 1
  }
}
  }
}

There should be enough there for the admin to diagnose most issues 
quickly.  I wrapped it in a "servicelist" so multiple definitions could 
be returned.  stdin/stdout/stderr, along with the env settings are 
probably not feasible, but I threw them in anyways.


On 10/16/2015 2:11 PM, Buck Evan wrote:

If you'll specify how you want it to look / work I'll (possibly) attempt to
provide a patch.

`s6-svstat --json` is my initial bid.

I'll try to match the nosh output as closely as is reasonable.

On Thu, Sep 24, 2015 at 4:27 AM, Laurent Bercot