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:
balena ps | grep "${SERVICENAME}_" | awk '{print $1}'
thus for example:
SERVICENAME=someservice
balena exec -ti $(balena ps | grep "${SERVICENAME}_" | awk '{print $1}') /bin/sh
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-api label 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.
DEBUGset 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.