On Jun 15, 2020, at 2:23 AM, xiao zhang via Tech-talk <
tech-talk at aps.anl.gov> wrote:
The only way of starting an IOC I have learned is by running the `st.cmd` script, which by default opens an iocsh shell on success. I am seeing 2 problems when running IOCs in containers:
1. The iocsh shell seems redundant as nobody will actually use it when run in containers. A way to start IOC which does not open up iocsh is a more light-weight solution.
I can’t help you with the container side at all, but it is possible to build an IOC that doesn’t start the IOC shell, or if you’re using one of the softIoc executables, tell that to not start the shell. In both cases though the IOC keeps its stdin, stdout
and stderr streams open, and it will continue to send messages to stdout/stderr.
If you’re building your own application binary, you have to edit your <app>App/src/<app>Main.cpp file, remove the line
iocsh(NULL) and replace the call to
epicsExit(0) with a call to epicsThreadExitMain().
If you’re running the softIoc or softIocPVA executable from Base, you can pass that the flag
-S (that’s an upper-case letter ’s’ to do the same thing as the above.
The result isn’t really any lighter-weight from the IOC’s perspective though, it just means you will have no ability to interact with the IOC while it’s running except through CA (or PVA). You can’t close stdin, send Control-C through it or use
kill -QUIT to stop it, you have to use a
kill -9 (SIGKILL) to make it die.
HTH,
- Andrew