Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: should not abort on name resolution failure #4

Open
lesinigo opened this issue Nov 26, 2022 · 0 comments
Open

Feature request: should not abort on name resolution failure #4

lesinigo opened this issue Nov 26, 2022 · 0 comments

Comments

@lesinigo
Copy link

On docker-compose and similar environment the DNS resolution of other containers/services only works when those containers actually are in status "Up", as opposed to containers not yet created or created but not yet started that will not be resolvable.

So you can't use wait4ports for a container that could have not been resolved yet and this starts to be a problem if you have a chicken-and-egg issue (eg. service A needs to resolve service B and also service B needs to resolve service A).

/ # wait4ports -s1 -t10 test=tcp://doesnotresolve:12345
doesnotresolve:12345 getaddrinfo: Invalid argument
No valid peers found in arguments!
Usage: wait4ports [-q] [-s <interval_seconds>] [-t <timeout_seconds>] [<name>=]<protocol>://<host>:<port> [...]

/ # wait4ports -s1 -t10 test=tcp://localhost:12345
Trying test (127.0.0.1:12345) ... failed.
Trying test (127.0.0.1:12345) ... failed.

wait4ports could be so much more useful if it could retry name resolution at every interval_seconds instead of simply failing at the first try. If strict backwards compatibility is desired, this could be an optional behavior to be enabled with a feature flag on the command line.

For comparison with other tools: wait4x and wait-for-it both work as described (they retry name resolution at every iteration).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant