Hi Florian
Thanks for sharing your experience. But I am not satisfied with the way it has to be.
As mentioned in my original post, the current method has 2 caveats:
1. Unnecessary overhead as entering the interactive shell of a running container is not part of a normal workflow
2. The container does not exit when the IOC process breaks
An iocsh-less way to start IOC solves both the above concerns as only `-d` option is required in this case. When the IOC process breaks, the container will exit immediately and tell the outer world that it is broken, so that a restart can be scheduled either manually or by an automatic container orchestrator.