From: Ben Franksen <ben.franksen@online.de>
To: supervision@list.skarnet.org
Subject: Re: logging services with shell interaction
Date: Fri, 23 Jun 2023 13:48:53 +0200 [thread overview]
Message-ID: <u740r5$dfh$1@ciao.gmane.io> (raw)
In-Reply-To: <ZJSB0fj3MAWkCnW9@CasperVector>
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
> <https://cpaste.org/?fa30831511a456b7=#ECwUd1YaVQBLUokynQbRYZq5wvBvXXeXo3bQoeL2rL4L>
> 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
next prev parent reply other threads:[~2023-06-23 11:49 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-19 8:59 Ben Franksen
2021-10-19 23:27 ` Laurent Bercot
2021-10-20 7:53 ` Ben Franksen
2021-10-20 18:01 ` Casper Ti. Vector
2021-10-23 15:48 ` Ben Franksen
2021-10-23 16:40 ` Casper Ti. Vector
2021-10-24 20:36 ` Ben Franksen
2022-04-22 10:40 ` Casper Ti. Vector
2023-06-22 17:16 ` Casper Ti. Vector
2023-06-23 11:48 ` Ben Franksen [this message]
2023-06-23 12:30 ` Casper Ti. Vector
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='u740r5$dfh$1@ciao.gmane.io' \
--to=ben.franksen@online.de \
--cc=supervision@list.skarnet.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).