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

On Tue, Aug 11, 2015 at 08:02:43AM +0200, Laurent Bercot wrote:
> On 11/08/2015 06:59, Rich Felker wrote:
> >AFAIK it was always SOCK_DGRAM.
>  It definitely wasn't, say, 6ish years ago. I have seen
> glibc's and uClibc's syslog() work with SOCK_STREAM. I didn't
> check the client code, maybe it tried both, but it *was*
> succeeding in logging stuff when there was a server listening
> on a /dev/log SOCK_STREAM.

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.

> >SOCK_DGRAM would be a huge advantage over SOCK_STREAM if it actually
> >worked the way I intended it -- that the initial connect() binds the
> >address even if syslogd isn't listening yet and keeps it working even
> >if syslogd is restarted. Unforunately it doesn't work that way, which
> >means there's no way for chrooted processes to re-establish their
> >syslog connections if syslogd goes down.
>  And that's why a correct supervision architecture must perform
> fd-holding on the fd outputting the logs. Which is only possible
> if it knows that fd before the client start, i.e. the client logs
> to stderr instead of syslog.
>  Are there real, current advantages of SOCK_DGRAM - not only
> hypothetical ones - and most importantly, is there a specification
> anywhere ?

I'm not sure.


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.