[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150811214119.GB21230@brightrain.aerifal.cx>
Date: Tue, 11 Aug 2015 17:41:20 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
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:
http://git.busybox.net/busybox/tree/sysklogd/syslogd.c?id=1_00#n561
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.
Rich
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.
