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