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.

Reply via email to