Hi Bazi, 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_stream { unix-stream("/tmp/stream_sock"); }; or 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. The appended trace shows, that there isn't a bind() between so_socket() = 4 and connect(4) As far as I know, bind() must be called before connect() to create the socket in the local filesys. It should be removed via unlink() after all work is done. Feedback or a hot-fix is very wellcome. Thanks a lot --Andreas Debug message:
syslog-ng -d -v io.c: connecting using fd 4 connecting fd 4, unixaddr: /tmp/dgram_sock Error connecting to AF_UNIX(/tmp/dgram_sock): Bad file number Error initializing configuration, exiting.
Strace:
18128: so_socket(1, 1, 0, "", 1) = 4 18128: fcntl(4, F_GETFL, 0x00000000) = 2 18128: fstat64(4, 0xFFBEF348) = 0 18128: getsockopt(4, 65535, 8192, 0xFFBEF448, 0xFFBEF440, 0) = 0 18128: fstat64(4, 0xFFBEF348) = 0 18128: getsockopt(4, 65535, 8192, 0xFFBEF448, 0xFFBEF444, 0) = 0 18128: setsockopt(4, 65535, 8192, 0xFFBEF448, 4, 0) = 0 18128: fcntl(4, F_SETFL, 0x00000082) = 0 18128: fcntl(4, F_SETFD, 0x00000001) = 0 io.c: connecting using fd 4 18128: write(2, " i o . c : c o n n e c".., 28) = 28 connecting fd 4, unixaddr: /tmp/dgram_sock 18128: write(2, " c o n n e c t i n g f".., 47) = 47 18128: connect(4, 0xFFBEF4A8, 110, 1) Err#2 ENOENT 18128: close(4) = 0 18128: close(4) Err#9 EBADF Error connecting to AF_UNIX(/tmp/dgram_sock): Bad file number 18128: write(2, " E r r o r c o n n e c".., 66) = 66 Error initializing configuration, exiting. 18128: write(2, " E r r o r i n i t i a".., 43) = 43 18128: llseek(0, 0, SEEK_CUR) = 41406 18128: lwp_mutex_wakeup(0xFF3E7CB0) = 0 18128: lwp_mutex_lock(0xFF3E7CB0) = 0 18128: lwp_sigredirect(0, SIGWAITING, 0x00000000) Err#22 EINVAL 18128: _exit(2)
-- 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
2004-02-16, h keltezéssel 19:09-kor Andreas Schulze ezt írta:
Hi Bazi,
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_stream { unix-stream("/tmp/stream_sock"); }; or 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.
The appended trace shows, that there isn't a bind() between so_socket() = 4 and connect(4)
As far as I know, bind() must be called before connect() to create the socket in the local filesys. It should be removed via unlink() after all work is done.
Feedback or a hot-fix is very wellcome.
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. What do you want to use those sockets for? Maybe you wanted to create message sources? -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
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
2004-02-17, k keltezéssel 09:04-kor Andreas Schulze ezt írta:
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.
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) -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
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). In this case it would be fine to let syslog-ng write messages _to_ a destination {unix-stream()} Let mediate a bit. Feedback is welcome, of course. Thx. -- 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
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).
Andreas, 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. -- Nate "We are discreet sheep; we wait to see how the drove is going, and then go with the drove." - Samuel Clemens
participants (3)
-
Andreas Schulze
-
Balazs Scheidler
-
Nate Campi