1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 <2020> 2021 2022 2023 2024 2025 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 <2020> 2021 2022 2023 2024 2025 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: How to run IOC in docker containers properly |
From: | "Johnson, Andrew N. via Tech-talk" <tech-talk at aps.anl.gov> |
To: | "Konrad, Martin" <konrad at frib.msu.edu> |
Cc: | EPICS tech-talk <tech-talk at aps.anl.gov> |
Date: | Wed, 17 Jun 2020 23:26:16 +0000 |
On Jun 17, 2020, at 5:59 PM, Konrad, Martin <konrad at frib.msu.edu> wrote:
procServ handles creating a pid.txt file for the IOC and will automatically restart an IOC that dies (if you ask it to) after some restart delay. If you don’t turn on the auto-restart (or you manually disabled it at runtime) you can connect to the console
and restart it manually in a single key-press. I don’t know if it deletes the pid.txt file when the IOC goes down and recreates it on restart but I would expect it to.
The reason that we would run procServ inside GNU Screen is that our engineers love the ability to scroll back through the console history, seeing the output when the IOC booted, and even going back to earlier runs etc. procServ doesn’t have a history buffer
at all, but screen (and presumably tmux) can provide that. We also rely on screen’s ability to support multiple people connecting to the console at once.
I think that would be best implemented in an external module. You don’t have to use the iocsh to run your IOCs – you can write your own shell, or set up the stdin/stdout/stderr streams to point to something else before running iocsh() in the main()
routine. You might want to disable readline if you do that though unless you are completely emulating a tty.
- Andrew
--
Complexity comes for free, simplicity you have to work for.
|