[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
