Re: Add SOCK_STREAM support for syslog

[Rich Felker <dalias@libc.org>]

On Sat, Nov 11, 2017 at 12:29:25AM +0000, Laurent Bercot wrote:
> >I suspect and seem to remember (but haven't looked at it lately) that
> >SOCK_STREAM has some undesirable properties from a standpoint of
> >logging and that SOCK_DGRAM is what you want if possible.
> 
>  Oh really? I would very much like to hear what those "undesirable
> properties" are. AIUI, datagrams are specified as unreliable, which
> is exactly what you *don't* want when logging, so it beats me why
> people would ever prefer SOCK_DGRAM over SOCK_STREAM. I suspect the
> answer is close to "because traditional syslogd is easier to implement
> with datagrams", which I do not hold in much regard.

I don't understand unix socket semantics well enough to be sure of all
the details, but here are a few as I understand them. Feel free to
correct if they're wrong.

If your primary goal is that no log data be lost, blocking SOCK_STREAM
might be preferable to you. Generally I consider "critical services
can't get delayed or deadlocked because of a problem with the logging
system" as a higher priority requirement. If you can't ssh in to fix a
problem because sshd is blocking in syslog() when you connect, you
have a big problem.

Datagram send succeeds or fails atomically -- either the full packet
is sent or nothing is. If you wanted to avoid blocking indefinitely
with stream sockets, you're stuck once you've sent a partial log line;
if you can't get the socket writable again to continue sending, you'll
either corrupt this and the next message, or you have to disconnect
and reconnect (may not be an option with chroot).

Datagram sockets are also nicer from a standpoint of being able to
restart the logging daemon while there are chrooted clients. As long
as a supervisor owns the socket and keeps it open, it just works to
kill the logging daemon and start a new one receiving on the socket.
But with streams, the logging daemon has to accept connections, and
there's no simple way to hand them off to a new/restarted daemon. And
if you can't do that, you cut off logging in all chrooted clients when
restarting the logging daemon.

Rich