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

Nate Campi syslog-ng@lists.balabit.hu
Tue, 17 Feb 2004 18:20:41 -0800

On Tue, Feb 17, 2004 at 07:51:59PM +0100, Andreas Schulze wrote:
> >>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.
> >
> >absolutely true. the client could not even try to bind it.
> >
> >>In destination {unix-dgram()} context syslogd acts like a server
> >>process and should do the bind().
> >
> >no. destination { unix-dgram() } is a client process. you want to use
> >source { unix-dgram() } instead. (source in the context of syslog-ng
> >means that messages are read _from_ this source, e.g. it behaves like a
> >server for other processes)
> Hmm. But if there is a client proc, that wants
> to read messages _from_ syslog-ng?
> In a context, where syslog-ng acts as a central
> message multiplexer (a server context, from this
> point of view).


I think the terminology is mixed up here, that's all. Usually when we
say "server", we think of data being sent to the client, like with a
HTTP server. In this case it's more like an X server, where the data
flow happens the other way, the client sends it into the server.

Syslog clients send data, syslog servers accept it. Once that's
established, the way syslog-ng works makes perfect sense.

> In this case it would be fine to let syslog-ng
> write messages _to_ a destination {unix-stream()}

Yes, a destination means syslog-ng is the client, sending data to a
listening server process.

"We are discreet sheep; we wait to see how the drove is going, and then 
go with the drove." - Samuel Clemens