2015-08-10 18:15 GMT-03:00 Laurent Bercot:
>
> Oh, it's a mess. A huge mess; there doesn't seem to be any authority
> on the details of the syslog protocol. No normative body, the client
> is in the libc, the server is an application: a definite recipe for
> success!
I don't know about syslog on /dev/log, but for syslog over a network
there is this:
RFC 3164 - The BSD Syslog Protocol
http://www.rfc-editor.org/rfc/rfc3164.txt
RFC 5424 - The Syslog Protocol (transport-independent part, obsoletes RFC 3164)
http://www.rfc-editor.org/rfc/rfc5424.txt
And the transport mappings:
RFC 5426 - Transmission of Syslog Messages over UDP
http://www.rfc-editor.org/rfc/rfc5426.txt
RFC 6587 - Transmission of Syslog Messages over TCP
http://www.rfc-editor.org/rfc/rfc6587.txt
RFC 5425 - Transport Layer Security (TLS) Transport Mapping for Syslog
http://www.rfc-editor.org/rfc/rfc5425.txt
RFC 6012 - Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog
http://www.rfc-editor.org/rfc/rfc6012.txt
Logger has --rfc3164 and --rfc5424 options, and has references to the
above documents in the source code and man page, so AFAICS it is aware
of and complies with them for messages sent over a network to a remote
syslog server, and uses the same code for communication over UNIX
domain sockets. The "non-transparent framing" described in the TCP
document (section 3.4.2 starting on page 7) is relevant to the
reported issue.
Glancing over the version 2.26.2 source code:
https://git.kernel.org/cgit/utils/util-linux/util-linux.git/plain/misc-utils/logger.c?id=v2.26.2
I understand that logger uses datagram mode UNIX domain sockets unless
there is a -T option without a -n option (check the logger_open and
unix_socket functions), and uses non-transparent framing in stream
mode, but with LF ('\n') instead of NUL ('\0') as the trailer
character, as suggested by the TCP mappings document (while
acknowledging that NUL is also in widespread use). And version 2.27
will add an --octet-count option to select octet-counting framing.
Moreover, when reading from stdin (check the logger_stdin function)
logger only sends a message when it receives LF characters (discarding
them) or detects an EOF. It copies verbatim every other character to
the output buffer, but later it uses string manipulation functions
that treat NUL as an end-of-string marker, so I guess that would
explain the weird behaviour of ignoring all input between a NUL and a
subsequent LF. This probably translates to "logger doesn't expect NUL
characters in its input stream, don't do that".
As for ucspilogd... who knows. The printf examples without the NULs
would supposedly work as expected using ucspilogd with option "stream
mode sockets using non-transparent framing with LF as trailer
character", if it had one, and piping to 'logger -T'. Or using
ucspilogd with option "datagram mode sockets", which would also make
musl syslog() work. And GNU libc syslog() works fine using ucspilogd
with current "stream mode sockets using non-transparent framing with
NUL as trailer character" behaviour :P
Cheers!
G.
Received on Wed Aug 12 2015 - 02:45:13 UTC