Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 13 Aug 2015 23:10:37 -0400
From: Rich Felker <>
Subject: Re: /dev/log: datagram, stream, both?

On Tue, Aug 11, 2015 at 11:53:38PM +0200, Laurent Bercot wrote:
> On 11/08/2015 23:41, Rich Felker wrote:
> >Busybox 1.0 syslogd:
> >
> >
> >
> >That's from 2004. We could go back even earlier but I don't know where
> >the syslogd was (or if it even had one) if we go further back.
>  I'm not denying there were SOCK_DGRAM servers. What I'm saying is that
> I had a SOCK_STREAM server and it worked, which means libcs had support
> for SOCK_STREAM clients.
>  And the glibc still does:
>  If there's no authoritative source asserting that /dev/log is a datagram
> socket and nothing else, I'm submitting a feature request to support
> SOCK_STREAM in musl's syslog(). I know it would horribly complicate the
> code, but I have something that works with glibc and doesn't with musl,
> and nobody wants that. :)

Obviously I'd rather not do this, but if there's a convincing argument
that it's needed for compatibility with real setups we could consider
it. Part of being a convincing argument would be showing that
SOCK_STREAM is a documented feature that's supposed to work rather
than historical baggage, but even then, since the current code works
with all widely used log daemons, I think we'd also want a strong
argument why stream is better than datagram for your setup.

If SOCK_STREAM support does end up being deemed a feature that should
be added, some careful consideration should be made to how the
fallback and reconnection logic should work. I suspect glibc does it
in a way that's less than ideal. I certainly would want to avoid any
robustness regressions for normal SOCK_DGRAM setups.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.