Am 20.10.21 um 01:27 schrieb Laurent Bercot:
>> we have a fair number of services which allow (and occasionally
>> require) user interaction via a (built-in) shell. All the shell
>> interaction is supposed to be logged, in addition to all the messages
>> that are issued spontaneously by the process. So we cannot directly
>> use a logger attached to the stdout/stderr of the process.
>
> I don't understand the consequence relationship here.
> > - If you control your services / builtin shells, the services could
> have an option to log the IO of their shells to stderr, as well as
> their own messages.
We do have control over them, theoretically, but adding this
functionality seems impractical. This is a complex piece of software,
built from multiple components maintained by different parties. There is
some sort of common framework for issuing messages but none of the
components strictly adhere to it. In other words, they use things like
printf all over the place. The only way I see to reliably get all the IO
for logging is to delegate this to an external process.
> - Even if you cannot make the services log the shell IO, you can add
> a small data dumper in front of the service's shell, which transmits
> full-duplex everything it gets but also writes it to its own stdout or
> stderr; if that stdout/err is the same pipe as the stdout/err of your
> service, then all the IO from the shell will be logged to the same place
> (and log lines won't be mixed unless they're more than PIPE_BUF bytes
> long, which shouldn't happen in practice). So with that solution you
> could definitely make your services log to multilog.
Yes, that would be possible. More or less what procServ does minus the
supervision aspect.
>> IOC=$1
>>
>> /usr/bin/procServ -f -L- --logstamp --timefmt="$TIMEFMT" \
>> -q -n %i --ignore=^D^C^] -P "unix:$RUNDIR/$IOC" -c "$BOOTDIR"
>> "./$STCMD" \
>> | /usr/bin/multilog "s$LOGSIZE" "n$LOGNUM" "$LOGDIR/$IOC"
>> ```
>>
>> So far this seems to do the job, but I have two questions:
>>
>> 1. Is there anything "bad" about this approach? Most supervision tools
>> have this sort of thing as a built-in feature and I suspect there may
>> be a reason for that other than mere convenience.
>
> It's not *bad*, it's just not as airtight as supervision suites make
> it. The reasons why it's a built-in feature in daemontools/runit/s6/others
> are:
> - it allows the logger process to be supervised as well
> - it maintains open the pipe to the logger, so service and logger can
> be restarted independently at will, without risk of losing logs.
>
> As is, you can't send signals to multilog (useful if you want to force
> a rotation) without knowing its pid. And if multilog dies, it broken
> pipes procServ, and it (and your service) is probably forced to restart,
> and you lose the data that it wanted to write.
> A supervision architecture with integrated logging protects from this.
Thanks, this answers my question perfectly.
>> 2. Do any of the existing process supervision tools support what
>> procServ gives us wrt interactive shell access from outside?
>
> Not that I know of, because that need is pretty specific to your
> service architecture.
It sure is.
> However, unless there are more details you have omitted, I still
> believe you could obtain the same functionality with a daemontools/etc.
> infrastructure and a program recording the IO from/to the shell. Since
> you don't seem opposed to using old djb programs, you could probably
> even directly reuse "recordio" from ucspi-tcp for this. :)
Interesting, I didn't know about recordio, will take a look.
Again, thanks a lot for the detailed response!
Cheers
Ben
--
I would rather have questions that cannot be answered, than answers that
cannot be questioned. -- Richard Feynman
Received on Wed Oct 20 2021 - 09:53:58 CEST