Date: Tue, 11 Aug 2015 08:02:43 +0200 From: Laurent Bercot <ska-dietlibc@...rnet.org> To: musl@...ts.openwall.com Subject: Re: /dev/log: datagram, stream, both? 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. > 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 ? -- Laurent
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.