From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=5.0 tests=MAILING_LIST_MULTI, NICE_REPLY_A autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 13655 invoked from network); 24 Oct 2021 20:36:18 -0000 Received: from alyss.skarnet.org (95.142.172.232) by inbox.vuxu.org with ESMTPUTF8; 24 Oct 2021 20:36:18 -0000 Received: (qmail 12413 invoked by uid 89); 24 Oct 2021 20:36:41 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Received: (qmail 12406 invoked from network); 24 Oct 2021 20:36:40 -0000 X-Injected-Via-Gmane: http://gmane.org/ To: supervision@list.skarnet.org From: Ben Franksen Subject: Re: logging services with shell interaction Date: Sun, 24 Oct 2021 22:36:06 +0200 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 In-Reply-To: Content-Language: en-US Am 23.10.21 um 18:40 schrieb Casper Ti. Vector: > On Sat, Oct 23, 2021 at 05:48:23PM +0200, Ben Franksen wrote: >> I agree. BTW, another detail is the special handling of certain control >> characters by procServ: ^X to restart the child, ^T to toggle auto-restart, >> and the possibility to disable some others like ^C and especially ^D; which >> is not only convenient but also avoids accidental restarts (people are used >> to ^D meaning "exit the shell"). > > These functionalities would need to be (and would perhaps have better > been) done outside of the `socat'/`recordio' pair, as separate commands > (like `s6-svc -k ...' or `touch .../down') or wrappers. `socat' simply > exits upon ^D/^C by default, so the IOC would not be hurt; I find this > enough to prevent most user errors, therefore more filtering of control > characters seems unnecessary. Sure, there may be other solutions, it's just another one of those details that need to be taken care of somehow. >> Our approach uses a somewhat hybrid mixture of several components. Since the >> OS is Debian we use systemd service units, one for each IOC. They are >> executing `/usr/bin/unshare -u sethostname %i runuser -u ioc -- softIOC-run >> %i` which fakes the host name to trick EPICS' Channel Access "Security" into >> the proper behavior, and then drops privileges. softIOC-run is the script of >> which I posted a simplified version, with the pipeline between procServ and >> multilog. Despite the disadvantages explained by Laurent, so far this works >> pretty well (I have never yet observed multilog to crash or otherwise >> misbehave). Finally, the configuration for all IOCs (name, which host do >> they run on, path to the startup script) all reside in a small database and >> there are scripts to automatically install everything, including automatic >> enabling and disabling of the service units. > > Frankly I find the above a little over-complicated, even discounting the > part about CA security which we do not yet involve. I think you might > be going to find our paper (after publication; it is to be submitted the > next week) interesting in simplifying IOC management. I am looking forward to it. You may want to post a link when it's done, here or on the EPICS mailing list. Cheers Ben -- I would rather have questions that cannot be answered, than answers that cannot be questioned. -- Richard Feynman