When releasing an app through the cloud builder, the images for services are not tagged in a way which would allow identifying which one applies to which service.
If I want to remote to the host OS of a device and debug a particular service from the context of that device, I would like to spawn a container based on the image, change the entrypoint to bash, and run some experiments.
hey @maciej.ldc, the name of the container follows servicename_imageId_releaseId, and yeah, one way is to get all parts of that name, but it’s also maybe simpler to just get the container ID by the name, matched on the servicename_ part? If you set the SERVICENAME env var, you can get the right container ID as:
would give you a prompt in the right service’s container. Of course needs adjustments for your own use case.
Using balena ps | grep "${SERVICENAME}_" | awk '{print $2}' would give you the corresponding image hash as well, that you can use to spawn a container. On the other hand, that won’t be the same setup as if the supervisor would have spawned it (none of the volumes, etc are set up the same way), so don’t think it’s really a viable path of a one-to-one comparison.
As for your question regarding the Supervisor API, the key is not available outside of the containers managed by the supervisor, and even there only in those where the io.balena.features.supervisor-apilabel is applied.
To go back to your original question, though, for some questions based on what we’ve seen in support so far, and how we ourselves develop:
what sort of experiments would you like to run?
would it work instead of what you attempt above, to incorporate instead a different behaviour in your service’s setup, such that based on an env var (e.g. DEBUG set to some value), the service is set up in a way that you want to experiment with? Somewhat along the lines of the example shown in How to debug a container which is in a crash loop? but can be more specific to your use case, and bigger changes to put things in debug behaviour.