Re: [PATCH 0/4] Add info on why process is down to statusfile
On 01/19/15 23:52, Laurent Bercot wrote:
> On 19/01/2015 21:55, Olivier Brunel wrote:
>> Side question: I see you haven't added support of the file "ready" into
>> s6-svstat, any reason?
>
> I hesitated, then decided against it, but that's not a strong decision.
>
> The argument was that s6-svstat shows the state of the service as it is
> seen by s6-supervise, i.e. purely the process up/down state. Introducing
> the notion of readiness into it would change things. For instance,
> s6-svstat currently prints the number of seconds that the process has
> been up; users may be more interested in knowing want the number of
> seconds that the process has been ready, and that needs storing another
> timestamp. The supervise/ready file could be used for that, but I'm
> not comfortable enough yet with tightly integrating readiness into the
> whole series of tools. In the beginning, I thought I could get away
> with s6-notifywhenup only, but it appears that modifications are
> spreading across several binaries - I need time to convince myself that
> it's not gratuitous feature creep and the utility is worth the increase
> in complexity. I'm paranoid like that.
I see... Well, thing is, as you said, support for the ready file is
already more than just s6-notifywhenup, since s6-supervise takes care of
removing it when needed, or s6-svwait also has support for it.
Which is why it already feels like an integral part of s6 (at least from
a user POV), and felt like a bug to me that the indication of a service
being ready was missing from s6-svstat (Seems inconsistent that only
some tools would support/be aware of that file, while others ignore it).
(Plus, it's pretty much only stating whether a file exists or not, in
terms of complexity s6-svstat is probably the lesser affected of the
tools actually :p)
I get your point re: integrating readiness into the whole suite though,
even though this feels like it might already be happening really.
Received on Tue Jan 20 2015 - 18:04:05 UTC
This archive was generated by hypermail 2.3.0
: Sun May 09 2021 - 19:44:19 UTC