Hi Avery.
You have it right. Your suggestion is essentially what I've done, as a
workaround, except I put the "intermediary" inside a docker base image, for
reuse. You can see it here:
https://github.com/bukzor/baseimage-docker/blob/master/image/bin/wait-for-services
The patch at hand eliminates the need to retry for $SVWAIT seconds if
sv-check exits with error before that period. This is nearly already the
behavior of sv-check, which is why my patch is only a single character.
(The rest of the script is eliminated if my other patch is accepted:
http://www.mail-archive.com/supervision_at_list.skarnet.org/msg00464.html) I
do this not from a need to get my system working -- it works -- but from a
desire to improve the ecosystem for all users.
To your "option flag" suggestion: I'm amenable, but I'd like to discuss
slightly more. The reason it didn't occur to make this behavior optional is
that it seems to be a strict improvement. I think there's only three cases
here:
1. Users that would have gotten immediate failure, and no amount of
spinning would help. These users will see their error delayed by $SVWAIT
seconds, but no other difference.
2. Users that would have gotten immediate failure, but could have gotten a
success within $SVWAIT seconds. All of these users will of course be glad
of the change.
3. Users that would not have gotten immediate failure. None of these users
will see the slightest change in behavior.
Do you have a particular scenario in mind when you mention "breaking lots
of existing installations elsewhere due to a default behavior change"? I
don't see that there is any case this change would break.
On Tue, Feb 17, 2015 at 10:31 AM, Avery Payne <avery.p.payne_at_gmail.com>
wrote:
> On 2/16/2015 5:08 PM, Buck Evan wrote:
>
>> My check is running from outside the docker, racing against runit.
>>
>
> I'm not clear on this. Am I understanding this correctly?
>
> + You have a service inside of a docker container
> + The service in the container is managed by runsv (which may or may not
> be under runsvdir)
> + You start the container
> + You start the service in the container (or it auto-starts as part of the
> container)
> + Your *host* for the container is attempting to check the status of the
> service inside the *guest* container
> + The check for the service is a ./check script inside the *guest*
> + You expect the ./check to block while waiting for the service, to
> confirm the service is ready and not "just starting".
>
> If this a correct understanding, consider using some intermediary program
> at the *host* level to run "sv check some-service" inside of the *guest*
> container, and then have the intermediary report back to the *host*. This
> would remove the need for a patch; the intermediary could
> block-while-waiting, etc. or perform any other strategy you need. Added
> bonus: by having a single intermediary integrated with docker, you can
> re-use it with other docker containers.
>
> If you really need the patch, I humbly suggest that you make the
> wait-for-check behavior into an option flag, instead of setting it as the
> default behavior. You would gain your desired outcome without breaking
> lots of existing installations elsewhere due to a default behavior change.
>
>
Received on Tue Feb 17 2015 - 19:02:02 UTC