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
