>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.
- 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.
>procServ is a process supervisor adapted to such situations. It allows an external process (conserver in our case) to attach to the service's shell via a TCP or UNIX domain socket. procServ supports logging everything it sees (input and output) to a file or stdout.
That works too.
>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.
>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.
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. :)
--
Laurent
Received on Wed Oct 20 2021 - 01:27:47 CEST