Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 11 Aug 2015 00:59:38 -0400
From: Rich Felker <>
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_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.


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.