Uneven way through which meshery opens up

so, guys I was trying to run meshery, and here I noticed an uneven way through which meshery opens up, when I tried to run mesheryctl system start -p docker it did pull all the required images and started what ever containers it wanted, but failed to start it up because it said my port was occupied. Here I have a question which is, does meshery only stick to a particular port in the PC? doesn’t it try to migrate it to another empty port ?

after that what I did was, I didn’t run mesheryctl system stop but instead I tried to run it with Kubernetes with the command mesheryctl system start -p Kubernetes this time it didn’t give me an error but straight up gave me a port where it was running on, but if I opened it nothing seem to work , and finally after I ran mesheryctl system start -p docker again and this time that particular port where kubernetes was deployed on got fired up and began to work.

I wonder why this happened ? I am using a WSL

so is this my personal networking issue or does meshery have a few vulnerabilities for which I could open up an issue,
by the way just for information I was trying to execute the commands in mesherytest xl sheet and encountered this issue

@Santosh_Sankranthi_v_s_a thanks for your post. It’s great.

To your first question, the Docker Compose configuration for Meshery is such that each container has a default network port assigned so that as a distributed system, when Meshery components are deployed, they know where to start communicating with each other. Each of Meshery’s components can be made to listen on non-default ports. See the guide on using multiple Meshery Adapters.

To your second question, please be aware that the -p flag of mesheryctl system start will actively update and switch your current meshconfig context (as persisted to ~/.meshery/config.yaml). On occasion, you might find mesheryctl system context create k8s -p kubernetes and mesheryctl system context switch k8s of help, so that you can control what is now two separate deployments of Meshery independently.

Regarding why Meshery didn’t seem to start on Docker the first time (but actually did) is due to a bug introduced in a recent Meshery release - [mesheryctl] Docker: False negative `system start` message · Issue #7594 · meshery/meshery · GitHub. // @Azanul.Haque @alphaX86

Regarding why you couldn’t see Meshery UI on the dynamically allocated port on your Kubernetes deployment, there is a known race condition that plagues the current implementation of the same logic that underpins this portion of system start and of system dashboard. Relevant issue - [mesheryctl] `system dashboard` to open up Meshery UI · Issue #3035 · meshery/meshery · GitHub. @hexxdump is to be working on this (I hope). // @Antonette.Caldwell

@Santosh_Sankranthi_v_s_a - [mesheryctl] Docker: False negative `system start` message · Issue #7594 · meshery/meshery · GitHub

@Santosh_Sankranthi_v_s_a I’d like to know a few things,

  • Value of env var DOCKER_HOST
  • Does docker ps work
  • Are there any changes done in docker client configuration?

@Santosh_Sankranthi_v_s_a set DOCKER_HOST to the value of endpoint of you current docker context. You can get the endpoint by executing docker context ls


(with a permanent fix forthcoming in mesheryctl :clap: )

1 Like