On 28/07/2015 09:07, Ido Perlmuter wrote:
> I'm looking for some advice how reading the service's stdout/stderr streams
> could be done in a more fool proof, general way.
Unfortunately, there isn't going to be a nice, non-hackish way to do it
without some support from your rc.log. You can't hijack a data stream at
run-time - except with black voodoo like strace, and indeed you don't
want that much blood and gore on your hands.
Your best bet is probably to implement your system as a middle layer
in the supervision system scripts: tell your users not to write "start"
functions in their rc.log scripts (resp. not to write ./run scripts for
their loggers) but to write "start.real" functions (resp. ./run.real
scripts).
Then, in the rc.log start (resp. ./run for the logger), do your magic,
i.e. duplicate your data, send a copy to the engine that will either
feed it to your reader when active or throw it away when no reader is
present, and send the other copy to rc.log start.real's (resp.
./run.real's) stdin.
If you don't mind files growing uncontrollably - which seems to be
Supervisor's way - then your "rc.log start" could be as simple as
"tee bigfile | rc.log start.real $2", and your tools could read from
bigfile.
A more elaborate setup could listen to a Unix socket and have a mini-server
that distributes the log stream to every client that connects;
rc.log start.real would be a permanent client, and you would spawn an
additional client for every instance of your tool that wants to read the
stream.
HTH,
--
Laurent
Received on Tue Jul 28 2015 - 09:45:45 UTC