Experimental Physics and
Industrial Control System

Mark Rivers via Tech-talk <tech-talk at aps.anl.gov> · Thu, 18 Jun 2020 14:57:53 +0000

> 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.

procServ does have the ability to write everything to a log file, so you can scroll back through that, going to earlier runs, etc.

> We also rely on screen's ability to support multiple people connecting to the console at once.

procServ supports that as well.  There is no limit on how many people can connect to the procServ session with local telnet.

Mark

________________________________
From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Johnson, Andrew N. via Tech-talk <tech-talk at aps.anl.gov>
Sent: Wednesday, June 17, 2020 6:26 PM
To: Konrad, Martin
Cc: EPICS tech-talk
Subject: Re: How to run IOC in docker containers properly

On Jun 17, 2020, at 5:59 PM, Konrad, Martin <konrad at frib.msu.edu<mailto:konrad at frib.msu.edu>> wrote:

Hi,
Just curious, why do you need procServ at all? You can run tmux (and
presumably Screen) as a systemd service if you want. You can run
tmux commands to start, stop, and restart an IOC.
Compared to screen and tmux, procServ is lighter and less complex. It
can also restart a crashed IOC process and it prevents users who are in
the habit of pressing Ctrl-C + Ctrl-D for logging out from accidentally
shutting down the IOC.

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.

While we're at it I would like to propose a forth solution: How about
beefing up the IOC itself so it can listen on a socket for connections
to the IOC shell? This would come with a few advantages (some of them
might only apply to systems running systemd):

...

Thoughts? Maybe a project for the upcoming online codeathon?

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.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System