Add SOCK_STREAM support for syslog

Add SOCK_STREAM support for syslog

[Jan Horstmann]

Hello,
some time ago there was a discussion whether musl-libc's syslog should
support SOCK_STREAM as a fall back if SOCK_DGRAM fails like glibc does
( http://www.openwall.com/lists/musl/2015/08/10/1 )
Later on a patch was posted to the mailing list: http://www.openwall.com/lists/musl/2017/08/21/3
Since we depend on this functionality we have applied this patch and are quiet happy with it.
I would like to know whether there are any plans to incorporate this patch into a future release?
Kind regards,
Jan

Re: Add SOCK_STREAM support for syslog

[Szabolcs Nagy]

* Jan Horstmann <J.Horstmann@mittwald.de> [2017-11-10 13:17:31 +0000]:
> some time ago there was a discussion whether musl-libc's syslog should
> support SOCK_STREAM as a fall back if SOCK_DGRAM fails like glibc does
> ( http://www.openwall.com/lists/musl/2015/08/10/1 )
> Later on a patch was posted to the mailing list: http://www.openwall.com/lists/musl/2017/08/21/3
> Since we depend on this functionality we have applied this patch and are quiet happy with it.
> I would like to know whether there are any plans to incorporate this patch into a future release?

i think you need to explain why you depend on this
to get consensus on the inclusion of the patch.

> Kind regards,
> Jan

Re: Add SOCK_STREAM support for syslog

[Rich Felker]

On Fri, Nov 10, 2017 at 03:07:49PM +0100, Szabolcs Nagy wrote:
> * Jan Horstmann <J.Horstmann@mittwald.de> [2017-11-10 13:17:31 +0000]:
> > some time ago there was a discussion whether musl-libc's syslog should
> > support SOCK_STREAM as a fall back if SOCK_DGRAM fails like glibc does
> > ( http://www.openwall.com/lists/musl/2015/08/10/1 )
> > Later on a patch was posted to the mailing list: http://www.openwall.com/lists/musl/2017/08/21/3
> > Since we depend on this functionality we have applied this patch and are quiet happy with it.
> > I would like to know whether there are any plans to incorporate this patch into a future release?
> 
> i think you need to explain why you depend on this
> to get consensus on the inclusion of the patch.

Is it mutually exclusive whether /dev/log is listening as SOCK_DGRAM
or SOCK_STREAM? If not, I think there's a race where connecting to
SOCK_DGRAM fails, then syslogd starts listening on both, and the
SOCK_STREAM connect succeeds in the fallback despite there being a
SOCK_DGRAM service available. Adoption of the patch is mainly blocked
on establishing that it does not harm any existing usage. 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.

Rich

Re: Add SOCK_STREAM support for syslog

[Laurent Bercot]

>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.

--
  Laurent

Re: Add SOCK_STREAM support for syslog

[Rich Felker]

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

Re: Add SOCK_STREAM support for syslog

[Laurent Bercot]

>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.

  But how can you tell the difference? The syslog() API does not
allow a process to specify what policy it wants: block or drop logs.
Relying on a system-wide setting, and an obscure one as that
(is /dev/log SOCK_STREAM or SOCK_DGRAM?), is a terrible way to
implement that policy. The right thing in this case is to always
do the reliable thing by default (don't drop data), and if a
process cannot afford to block when logging, then it should be
using other mechanisms to log.
  Like, for instance, writing to a non-blocking file descriptor,
with a call to poll() beforehand and giving up after some timeout.
syslog() is just the wrong API for this. (It's the wrong API for
pretty much everything.)
  skarnet.org programs always give the user an option to time out
when they may block. It's the only way to be safe. If sshd does not
do this, it's a design failure.


>Datagram send succeeds or fails atomically -- either the full packet
>is sent or nothing is.

  This is a good argument, but is only as important as the integrity
of records. Between losing an entire log line and conflating a partial
one with the next, I'm not sure what's worse; syslog data is text,
which is easily recoverable, and it can be argued that some info is
better than no info. it is, again, a policy decision, one that the
libc shouldn't have to make.


>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.

  This implies a monolithic syslogd. My argument for SOCK_STREAM is
precisely that it allows syslogd to be implemented via a super-server,
inetd-like, with a "syslogd" program only handling one client
connection; in that case you can easily restart the server without
impacting existing clients. And to me, doing away with a monolithic
syslogd is the whole point of using SOCK_STREAM, so this argument
holds no water.

--
  Laurent