Experimental Physics and
Industrial Control System

Hey,

to the caveats:
1) I agree, entering the iocsh is not part of a normal workflow. We only
enter the interactive shell of the container for debugging. In normal
operation the shell is detached and not used. So there is not really an
overhead.
2) I cannot confirm this behaviour. In our cases, when the ioc breaks
the container exits. Which command are you using within you container?
In our case the command which is started inside the container is simply
`st.cmd`. So if the IOC breaks, the command of the container is finished
and thus the container stops.

Best regards,
Florian

Am 15.06.2020 um 10:03 schrieb xiao zhang via Tech-talk:
> 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.

--
Dr. Florian Feldbauer

Ruhr-Universität Bochum
Experimentalphysik I AG
Universitätsstr. 150
Fach-Nr. 125
D-44801 Bochum

Office: NB 2/134
Phone:  (+49)234 / 32-23563
Fax:    (+49)234 / 32-14170
https://paluma.ruhr-uni-bochum.de