-
Notifications
You must be signed in to change notification settings - Fork 26
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
Timeout in case of one-shot container #19
Comments
I don't know a good way to differentiate between an expected exit, an unexpected exit, and a container that hasn't started yet. PR's welcome, but it should gracefully handle the different scenarios. Ideally docker-stack-wait.sh -f label=wait-service=true $stack_name |
I know about the filter option. But it's not suitable in my case because the I think the better option is to introduce a new argument - |
Any updates on this? |
None here. I haven't seen any PRs that implement this while also differentiating between an expected exit, an unexpected exit, and a container that hasn't started yet. |
Well, it's hard to reproduce the exact case. As I mentioned before, the new argument (i.e. Let me give you a situation - I have 7 services and I need to wait for 6 of them.
Requires 6 labels.
Requires only 1 label. Obviously, the second one is much easier to read and maintain. |
This fixes sudo-bmitch#19
@sudo-bmitch replicated-job is supported now by docker stack deploy, but your script still runs into the timeout. So can I assume these jobs are still not supported? |
@pschichtel see my comment above #19 (comment) |
ah sorry I missed that. In that case I might work on this soon-ish. I'm currently ignoring the affected services as suggested, as it still works out fine in this setup timing-wise, but I'd prefer a proper solution. |
I'll probably wait and see how these turn out: |
I have 7 services in my
docker-compose.swarm.yml
. Everything run as a daemon exceptstorage-minio-client
service.The
storage-minio-client
acts like a one-shot container - executes command defined by an entrypoint and exits.The image was build from Dockerfile:
The
setup-buckets.sh
creates buckets and exits with code 0.This kind of container causes
docker-stack-wait
to timeout, however services were deployed successfully.Also, Portainer shows complete status for the
storage-minio-client
service.Logs from the script:
Looks like the script expects all services are in running state.
P.S. I found a workaround - added
sleep 300
in my bash script that keeps thestorage-minio-client
container running, so thedocker-stack-wait
finishes successfully.P.P.S. Similar issue was reported earlier.
The text was updated successfully, but these errors were encountered: