CODEWITHSUNDEEP
dockerdocker-swarm
drmrbrewer
drmrbrewer

Reputation: 13029

Get full text for warning in docker service update

When running the following command:

docker service update captain-captain --force

I am briefly seeing a warning:

no suitable node (scheduling constraints not satisfied on 2 nodes; host-mo…".

enter image description here

But I can't see the full text to understand this properly. Nor is there a task ID e.g. mqo2k39bax94y6fiq7boxxtge which I've seen in the past for similar warnings/errors, which I can inspect with docker inspect mqo2k39bax94y6fiq7boxxtge.

The warning does disappear after a short time and the update seems to complete OK, so it's clearly not fatal, but I want to understand a bit more about why it is showing in the first place.

Upvotes: 2

Views: 1302

Answers (1)

drmrbrewer
drmrbrewer

Reputation: 13029

The key was to add --detach to unblock the terminal (so that it doesn't wait for the task to finish):

docker service update captain-captain --force --detach

Then quickly (while the truncated message would still be showing had the terminal no been unblocked:

docker service ps captain-captain

ID             NAME                    IMAGE                      NODE         DESIRED STATE   CURRENT STATE           ERROR                              PORTS
1ejhe98ozrdn   captain-captain.1       caprover/caprover:1.10.1                Ready           Pending 2 seconds ago   "no suitable node (host-mode p…"   
o9y4cfwlsqy7    \_ captain-captain.1   caprover/caprover:1.10.1   mercian-31   Shutdown        Running 2 seconds ago

Then quickly grab the ID of the task showing the error, and inspect it before the error is resolved:

docker inspect 1ejhe98ozrdn

Within that output you'll find the full error, in this case:

"Err": "no suitable node (scheduling constraints not satisfied on 2 nodes; host-mode port already in use on 1 node)"

Quite why docker can't just show the full error message in the first place, without having to just through these hoops, I'm not sure.

As an aside, docker seems not to be stopping the old instance before it schedules the new one even though we're definitely using stop-first.

Credit for this answer goes here.

Upvotes: 3

Related Questions