Thanks for the suggestions guys. You're not going to be able to get a separate view of stdout and > stderr since you've redirected those to the same place. As long as > that isn't an issue it should be pretty easy to solve this the right > way instead of using strace, funky interstitial logging scripts, > parsing the log script, etc. Assuming you're on linux and the output > file descriptor is stable, "the right way" is to use procfs to > directly read against the file descriptor that the logger is > outputting to. I don't know which file descriptors tinylog uses but > s6-log uses fd 4 for its file. >
I forgot to mention that I have no interest in a separate view of the channels, so that's fine. I've made a quick check with perp and it is using fd 4 as well. > > The below is for s6-log, something similar is doable with perp: > Use s6-svstat to find out the logger pid, parse the output for the > process id, then readlink /proc/$loggerpid/fd/4 to get the logger > output location (or, if you're feeling lazy, just tail the fd > directly). Caveats: you'll need account access to read > $svcdir/$svc/log/supervise as well as /proc/$pid/fd, and the current > fd 4 will stop being useful when a file rotation happens. > Cool, this works. > I'd say write the management compatibility layer (which it sounds like > you already have), and then use the energy you'd spend fighting unix > pipes on teaching people how to make the most out of perp. > I suppose enforcing a certain logging policy for anyone whishing to use my shell is somewhat unavoidable, but I'll keep looking into those options to see what I can do to be as unobtrusive as possible. Though your suggestion was meant to avoid that, I *could* try to read the rc.log (/log/run) scripts to check which logger is being used (with a simple search of tinylog, s6-log, svlogd, etc.) in order to know which fd I need. > [0] Most of the services at work don't log anything locally and > instead send data down a zmq socket to N log brokers that forward > along to their subscribers. It's pretty heavy-weight, really slick, > and mostly functional. That's cool, never heard of ZeroMQ being used for logging, this is something to examine regardless of this exercise. Thanks again, Ido.
