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.