[syslog-ng]Bug in unix_stream/dgram() dest drivers 1.6.0rc4

[Andreas Schulze]

>>it seems I've found a bug in the unix_stream/unix_dgram
>>destination drivers.
>>
>>The problem is, that running sysng with something like
>>
>>	destination d_dgram  { unix-dgram("/tmp/dgram_sock"); };
>>
>>it doesn't create the socket in the file system, so the
>>connect() fails. Seems that bind_unix_socket() is never called.
> 
> bind is called by the program creating the UNIX dgram socket. in this
> case you instructed syslog-ng to connect to such a socket, where binding
> is not necessary.

Yepp. But the problem ist, that syslogd doesn't start, if the socket
wasn't created via bind() by a running program.

I think, the general question is:
Who is responsible to create (bind()) the socket?
The client or the server process? In general IMHO the server process.

In destination {unix-dgram()} context syslogd acts like a server
process and should do the bind().

Of course, in source {unix-dgram()} context syslogd acts like a client
process and could assume, that a running server has created the socket
before.

> What do you want to use those sockets for? Maybe you wanted to create
> message sources?

I want to use AF_UNIX() destination stuff as some kind
of message queues for syslogd.

syslogd writes to, some other apps reads from and proccess
and transform the messages.

-- 
Best regards --Andreas Schulze
                [phone: +49.5246.80.1275, fax: +49.5246.80.2275]

| I believe, it was Dennis Ritchie who said something like:
|   "C is rarely the best language for a given task,
|    but it's often the second-best".
| The implication being that: "[...]"
|     http://www.ioccc.org/1990/dds.c