[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150811045938.GA21230@brightrain.aerifal.cx>
Date: Tue, 11 Aug 2015 00:59:38 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: /dev/log: datagram, stream, both?
On Mon, Aug 10, 2015 at 11:04:51PM +0200, Laurent Bercot wrote:
>
> Hello,
> I just noticed that musl's syslog() uses a datagram socket.
> This will only work if the syslogd implementation has opened
> /dev/log as a datagram socket too.
AFAIK it was always SOCK_DGRAM.
> Last time I checked, which was a certain number of years ago,
> /dev/log was a SOCK_STREAM. And it was great, because it allowed
> me to very easily whip up a superserver-based implementation of
> syslogd in a few lines of code. I tested it, it worked, with all
> the syslog() implementations I could find.
>
> But now, it appears to have changed, and my elegant approach
> isn't working anymore. Gah!
> A Web search is pretty confusing: nobody seems to agree, there
> doesn't seem to be an authority on this. So I'm asking here: is
> /dev/log supposed to be a SOCK_DGRAM now? Is there a normative
> body somewhere? anything else than "rsyslogd decides and libcs
> have to adapt"? What are the reasons to use SOCK_DGRAM over
> 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.
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.
