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=-1.1 required=5.0 tests=MAILING_LIST_MULTI, NICE_REPLY_A,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 10888 invoked from network); 23 Jun 2023 11:49:08 -0000 Received: from alyss.skarnet.org (95.142.172.232) by inbox.vuxu.org with ESMTPUTF8; 23 Jun 2023 11:49:08 -0000 Received: (qmail 26159 invoked by uid 89); 23 Jun 2023 11:49:30 -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 26152 invoked from network); 23 Jun 2023 11:49:30 -0000 X-Injected-Via-Gmane: http://gmane.org/ To: supervision@list.skarnet.org From: Ben Franksen Subject: Re: logging services with shell interaction Date: Fri, 23 Jun 2023 13:48:53 +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:102.0) Gecko/20100101 Thunderbird/102.11.0 Content-Language: en-US In-Reply-To: Hi Caspar thanks for the heads-up; this is certainly an interesting project, but for me to start playing with it only makes sense if and when it has matured to the point where there is a minimum of documentation (-h/--help or something like that) and ideally some sort of revision control, too. I may be (barely) able to debug such low-level C code if I notice it misbehaving but to reverse-engineer what it is supposed to do is beyond my abilities. Cheers Ben Am 22.06.23 um 19:16 schrieb Casper Ti. Vector: > On Thu, Oct 21, 2021 at 02:01:29AM +0800, Casper Ti. Vector wrote: >> As has been said by Laurent, in the presence of a supervision system >> with reliable logging and proper rotation, what `procServ' mainly does >> can be done better by something like `socat' which wraps something like >> `recordio', which in turn wraps the actual service process (EPICS IOC). >> The devil is in the details: most importantly, when the service is to >> be stopped, the ideal situation is that the actual service process gets >> killed, leading to the graceful exit of `recordio' and then `socat'. > > It is found that socat does not do I/O fan-in/fan-out with multiple > clients; it also assumes the `exec:'-ed subprocess is constantly present > (i.e. it does not handle IOC restarting). So I have written a dedicated > program, ipctee (see below for link to source code), that does this. > I have also written a program, iotrap, that after receiving a > terminating signal, first closes the stdin of its children in the hope > that the latter exits cleanly, and after a tunable delay forwards the > signal. This way IOCs are allowed to really run their clean-up code, > instead of just being killed instantly by the signal. > >> So the two wrapping programs need to propagate the killing signal, and >> then exit after waiting for the subprocess; since `procServ' defaults >> to kill the subprocess using SIGKILL, `recordio' also needs to translate >> the signal if this is to be emulated. `socat' does this correctly when >> the `sighup'/`sigint'/`sigquit' options are given for `exec' addresses, >> but its manual page does not state about SIGTERM. `recordio' does not >> seem to propagate (let alone translate) the signal; additionally, its >> output format (which is after all mainly used for debugging) feels too >> low-level to me, and perhaps needs to be adjusted. > > Closer inspection of recordio revealed that it was designed in a smarter > way: after forking, the parent exec()s into the intended program, and > the children is what actually does the work of I/O forwarding. This way > recordio (the children) does not need to forward signals. Based on it, > I have written a program, recordln, that performs more line-oriented > recording: line fragments (without the line terminator) that go through > the same fd consecutively are joined before being copied to stderr. > >> At the facility where I am from, we use CentOS 7 and unsupervised >> procServ (triple shame for a systemd opponent, s6 enthusiast and >> minimalist :(), because we have not yet been bitten by log rotation >> problems. It also takes quite an amount of code to implement the >> dynamic management of user supervision trees for IOCs, in addition >> to the adjustments needed for `recordio'. To make the situation even >> worse, we are also using procServControl; anyway, I still hope we can >> get rid of procServ entirely someday. > > Source code for the programs above are available (licence: CC0) at > > These programs can be tested with (in three different terminals): > $ ipctee /tmp/in.sock /tmp/out.sock > $ socat unix-connect:/tmp/in.sock exec:'recordln iotrap /bin/sh',sigint,sigquit > $ socat unix-connect:/tmp/out.sock - > Please feel free to tell me in case you find any defect in the code. > The dynamic management of IOC servicedirs is being developed, and will > be tested internally here before a paper gets submitted somewhere. > -- I would rather have questions that cannot be answered, than answers that cannot be questioned. -- Richard Feynman