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.