On 27/01/2015 01:10, Laurent Bercot wrote:
> Something like that. I haven't given it any thought yet
So I've experimented a lot with that. I've put in knobs
and turned and tweaked them, I've put guards on the number of
forks per second, and guards on the last time since a fork
happened, and I've made it possible to fork several handlers
at a time or only one handler at a time, etc. etc.
Nothing is satisfying. The overwhelming conclusion to my
experiments was: it's doable, but safety is in direct opposition
to reliability here - the functionality has conflicting goals.
Either the user risks forking a zerg swarm, or he risks missing
log lines. It's possible to still get notification of a missed
log line even without the content, but it's not possible to predict
what content will be missing.
Unix was clearly not made for this. You definitely can't safely
and reliably make a control flow depend on an arbitrary data flow.
So, I did what I usually do in those cases: push the problem onto
the users. :P
I went back to the "log to a file" approach, but of course I didn't
make s6-log write to files. I just added a "log to stdout" directive.
So if you want to be notified when a certain line arrives, you just
start s6-log by pipelining it into a long-lived program that notifies
you when it gets a line; the s6-log instance should have a script
that, among other things, selects the interesting line and sends it to
stdout.
(If s6-log is supervised, when you pipeline, make sure s6-log gets
the run script's pid.)
That's one long-lived program that reads lines and does stuff, instead
of a flurry of short-lived programs. I feel a lot more comfortable with
that. The program can even die when it's not interested anymore, s6-log
will just stop storing stuff to send to stdout after a failed write.
I've used the opportunity to overhaul s6-log and make some changes.
Notably, there can now be ISO 8601 timestamps - for the log contents,
not for the archive filenames. Less notably, but artistically nice:
the script now lives in the stack, not in the heap.
Available on the current s6 git head. (Needs the current skalibs git
head.) Please tell me if it works for you.
--
Laurent
Received on Sat Feb 07 2015 - 16:17:22 UTC