On 12/08/2015 04:45, Guillermo wrote:
> I don't know about syslog on /dev/log, but for syslog over a network
> there is this:
Yeah, I know about the syslog RFCs. The mild way to put it is that
they're about as useful, well-engineered and enticing as a steaming
pile of donkey shit. And donkey shit can at least be used as manure.
Logs are data, if they need to be transported over the network,
there's no lack of complex, over-engineered and insecure ways to
transport data over the network - no need to come up with yet
another one specifically for logs, with its own quirks and
idiosyncratic formatting that peeks into user content when it
has no business doing so. You want to standardize a universal
format for logs (gl with that), then write a RFC about a universal
format for logs, don't mix that with a network protocol, like,
duh.
The only part of syslog that is worth normalizing is the
interaction between syslog() and syslogd, on the *local* machine,
because there's a lot of code using syslog() that doesn't care
about the network, and several implementations of syslogd. And,
of course, that's exactly the part those RFCs do not talk about.
It shouldn't come as a surprise when you know that Eric Allman,
of sendmail shame, is the original syslog designer, and the author
of RFC 5424, Rainer Gerhards, is also the main author of rsyslogd.
Do these people actually get *respect* for what they do? Geez this
community lacks critical thinking.
> Or using
> ucspilogd with option "datagram mode sockets", which would also make
> musl syslog() work.
It's more complicated than that. A datagram syslogd server cannot
listen() and accept(); it receives messages from every process that
uses syslog(). A datagram /dev/log socket enforces the fan-in,
enforces a single instance of syslogd that has to analyze and
authenticate every single log message from the whole machine, which
is precisely what I want to avoid; ucspilogd makes no sense in this
case, you have to use a complete (and big and inefficient) syslogd
implementation.
ucspilogd relies on the fact that there's a SOCK_STREAM super-server
above it to fork an instance per openlog() connection, and that its
stdin is private to this connection. That's what allows it to be so
simple - and not having the syslog() client try talking to a
SOCK_STREAM socket completely defeats it.
> And GNU libc syslog() works fine using ucspilogd
> with current "stream mode sockets using non-transparent framing with
> NUL as trailer character" behaviour :P
ucspilogd doesn't care about the chosen trailer character. It will
treat \0 and \n equally as line terminators - which is the only
sensible choice when logging to a text file and prepending every
line with some data.
glibc syslog() works because it does some ugly, ugly things like
trying with SOCK_DGRAM, and retrying with SOCK_STREAM if it failed.
In the absence of normalization for syslog(), I'm afraid this is
the only possible behaviour, though; I've swallowed my tears and
submitted a feature request to musl.
--
Laurent
Received on Wed Aug 12 2015 - 05:54:41 UTC