[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Mon, 10 Aug 2015 23:04:51 +0200
From: Laurent Bercot <ska-dietlibc@...rnet.org>
To: musl@...ts.openwall.com
Subject: /dev/log: datagram, stream, both?
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.
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?
If anyone needed another reason not to use syslog: underspecified
protocol with a client in the libc but an external server. Wheee!
--
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.
