Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <55C911F3.2090809@skarnet.org>
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.