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