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