Quoting mett ([email protected]): > by the way, what do u think about > what is written on that page regarding > logging? > > http://jdebp.eu./FGA/unix-daemon-design-mistakes-to-avoid.html > > I was thinking if there is a better > way of logging, might be worth to try it.
You asked the above of Tom <[email protected]>, not me, but I'll take a swing at it, anyway. 1. I respect author Jonathan de Boyne Pollard, quite a bit. He's always learned, but also cranky and sometimes eccentric: I don't mean 'eccentric' as derogation, but sometimes I have doubts about his sense of perspective. 2. The page's comments about 'syslog()" are probably (my surmise) directed specifically at the primordial Syslog implementation that Linux inherited from BSD, e.g., his repeated complaint that syslog() 'UDP for its remote-logging transport'. That was true _early_ in the history of Syslog, but was later remedied, and that limitation was never true of the rsyslog fork. 3. Here we get to the perspective problem: He doesn't like the fact that 'syslog()' first mixes incoming log streams and then follows rulesets to separate them back out again, calling that a 'waste of time and effort'. (This trait is also shared by Syslog's main successors, rsyslog and syslog-ng.) In part to avoid that 'waste', he urges that processes just log to stderr -- which by implication would then need to be picked up by something. He has in mind Daniel J. Bernstein's daemontools (which he approves of, generally) or equivalent _or_ some other receiver. (For the most part, he's pushing daemontools.) Jonathan's entitled to his opinion, of course, but some of us actually _like_ the facilities that Syslog-derived logging daemons provide, and don't consider their mixing-then-unmixing oddity all that wasteful. It might oo _might not_ be the ideal design if one were starting from scratch in 2018 to design logging infrastructure, but I for one am disinclined to throw away the entire well-developed administrative scheme just because it _might_ have been done differently and the results _might_ have been better. That's not to say I'd refuse somthing better than rsyslog (or syslog-ng_, just that it'd have to be _very significantly_ better before I'd bother trying it. (Your mileage may differ.{tm}) _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
