[logs] syslog implementation

bet@private

I just listened in on an eye-opening discussion of syslog problems.
The context was Linux, both with syslogd and syslog-ng, and
logrotate; but I suspect these problems may happen elsewhere.

- syslogd removes and re-creates /dev/log when it catches a HUP,
  even if the cfg hasn't changed; this busts filehandles on /dev/log
  that long-lived daemons hold. Various syslog client
  implementations break to various degrees when this happens; the
  worst of them fail over to logging at the serial console and can
  produce a decent simulation of a system crash when the log traffic
  is high enough. And no matter how robustly the clients are
  implemented, there's an unnecessary window of message loss.

- the sharedscripts setup for logrotate gets the order of HUP and
  compress wrong, introducing a much, much bigger window of
  message loss

- dgram implementations (both inet and unix) tend to be less
  inclined to die horribly, but more inclined to lose messages, than
  streams.

All-up I'm left with such a bad taste that I finally appreciate why
djb elected to junk the entire kit and kaboodle. multilog looks
really, really good all of a sudden.

Of course the unsupportable (non-open-source) daemontools
implementation, with it's very djb-esque "compatibility? who cares"
design is not what I'm looking for.

Has anybody contemplated a design that:

 - offers the syslog(3) API;

 - implements it by opening a pipe to a logger program, which

 - reads /etc/syslog.conf in the standard format, and

 - writes the msgs in the same format as syslogd to the requested
   files, or sends them to the requested remote server?

I.e. a syslogd-compatible implementation without the central daemon.

Of _course_ I'd want a superset implementation that offers
non-standard extensions to support syslog-ng-style filtering, sane
timestamps, fine-tuneable control over whose timestamp ends up on
the msg in remote-logserver implementations, etc. But let those be
extensions over something that's drop-in compatible with the
existing standard, so you build a system with it and end up fixing
_all_ apps, not just those that are rewritten to interact with a
wildly different logging strategy.

-Bennett