Hi, I've been running 2.0.6 on Solaris 10 and it all seemed to be working fine. On a new application I have found that it loses messages. This application sends 3-7000 messages/sec. Part of these messages contains a unique ID which increments. When I run the syslogd as supplied with Solaris 10 then all messages get logged, but when I use syslog-ng then it loses messages. On a Sun V210 I see these messages message overflow on /dev/log minor #6 -- is syslogd(1M) running? message overflow on /dev/log minor #6 -- is syslogd(1M) running? message overflow on /dev/log minor #6 -- is syslogd(1M) running? on the console, and eventually there is a hardware reset and the server reboots. I have tried running syslogd to just pass messages on to syslog-ng and this doesn't cause the hardware reset, but still loses some messages. I have also tried the time_sleep and log_fetch_limit options with no success. I have noticed that syslogd is multi-threaded but syslog-ng is only single threaded. Is this what is causing these messages to get missed? Are there any plans for a threaded version? Anyone have any ideas as to how to get all messages logged with syslog-ng? Regards Andy
On Wed, 2008-02-20 at 14:32 +0000, AndyH@nominet.org.uk wrote:
Hi,
I've been running 2.0.6 on Solaris 10 and it all seemed to be working fine. On a new application I have found that it loses messages. This application sends 3-7000 messages/sec. Part of these messages contains a unique ID which increments.
When I run the syslogd as supplied with Solaris 10 then all messages get logged, but when I use syslog-ng then it loses messages. On a Sun V210 I see these messages
message overflow on /dev/log minor #6 -- is syslogd(1M) running? message overflow on /dev/log minor #6 -- is syslogd(1M) running? message overflow on /dev/log minor #6 -- is syslogd(1M) running?
on the console, and eventually there is a hardware reset and the server reboots.
I have tried running syslogd to just pass messages on to syslog-ng and this doesn't cause the hardware reset, but still loses some messages. I have also tried the time_sleep and log_fetch_limit options with no success.
I have noticed that syslogd is multi-threaded but syslog-ng is only single threaded. Is this what is causing these messages to get missed? Are there any plans for a threaded version?
Anyone have any ideas as to how to get all messages logged with syslog-ng?
I don't think it is related to multithreaded/singlethreaded case. On Solaris, syslog-ng itself is multithreaded too, as the door() mechanism used to transport messages from application to syslogd requires that. syslog-ng issues a single getmsg() call for each poll() iteration, the log_fetch_limit() is ineffective in this case. Can you check if this patch solves/improves the behaviour? Thanks. diff --git a/src/afstreams.c b/src/afstreams.c index 009b074..d0a76f3 100644 --- a/src/afstreams.c +++ b/src/afstreams.c @@ -134,7 +134,7 @@ afstreams_sd_init(LogPipe *s, GlobalConfig *cfg, PersistentConfig *persist) close(fd); return FALSE; } - self->reader = log_reader_new(streams_read_new(fd), LR_LOCAL | LR_NOMREAD | LR_PKTTERM, s, &self->reader_options); + self->reader = log_reader_new(streams_read_new(fd), LR_LOCAL | LR_PKTTERM, s, &self->reader_options); log_pipe_append(self->reader, s); if (self->door_filename) This will cause the log-fetch-limit() option to become effective, thus several messages are going to be fetched for every iteration, this can easily multiply performance. Please also check if the local messages get mangled in any way, I seriously doubt that would happen, but messing with message transports always carries some risk. -- Bazsi
On Wed, 2008-02-20 at 18:30 +0100, Balazs Scheidler wrote:
On Wed, 2008-02-20 at 14:32 +0000, AndyH@nominet.org.uk wrote:
When I run the syslogd as supplied with Solaris 10 then all messages get logged, but when I use syslog-ng then it loses messages. On a Sun V210 I see these messages
message overflow on /dev/log minor #6 -- is syslogd(1M) running? message overflow on /dev/log minor #6 -- is syslogd(1M) running? message overflow on /dev/log minor #6 -- is syslogd(1M) running? ...
diff --git a/src/afstreams.c b/src/afstreams.c index 009b074..d0a76f3 100644 --- a/src/afstreams.c +++ b/src/afstreams.c @@ -134,7 +134,7 @@ afstreams_sd_init(LogPipe *s, GlobalConfig *cfg, PersistentConfig *persist) close(fd); return FALSE; } - self->reader = log_reader_new(streams_read_new(fd), LR_LOCAL | LR_NOMREAD | LR_PKTTERM, s, &self->reader_options); + self->reader = log_reader_new(streams_read_new(fd), LR_LOCAL | LR_PKTTERM, s, &self->reader_options); log_pipe_append(self->reader, s);
if (self->door_filename)
This will cause the log-fetch-limit() option to become effective, thus several messages are going to be fetched for every iteration, this can easily multiply performance.
Please also check if the local messages get mangled in any way, I seriously doubt that would happen, but messing with message transports always carries some risk.
Can you please send feedback on this patch? Thanks. -- Bazsi
syslog-ng-bounces@lists.balabit.hu wrote on 21/02/2008 15:19:15:
On Wed, 2008-02-20 at 18:30 +0100, Balazs Scheidler wrote:
On Wed, 2008-02-20 at 14:32 +0000, AndyH@nominet.org.uk wrote:
When I run the syslogd as supplied with Solaris 10 then all messages
get
logged, but when I use syslog-ng then it loses messages. On a Sun V210 I see these messages
message overflow on /dev/log minor #6 -- is syslogd(1M) running? message overflow on /dev/log minor #6 -- is syslogd(1M) running? message overflow on /dev/log minor #6 -- is syslogd(1M) running? ...
diff --git a/src/afstreams.c b/src/afstreams.c index 009b074..d0a76f3 100644 --- a/src/afstreams.c +++ b/src/afstreams.c @@ -134,7 +134,7 @@ afstreams_sd_init(LogPipe *s, GlobalConfig *cfg, PersistentConfig *persist) close(fd); return FALSE; } - self->reader = log_reader_new(streams_read_new(fd), LR_LOCAL | LR_NOMREAD | LR_PKTTERM, s, &self->reader_options); + self->reader = log_reader_new(streams_read_new(fd), LR_LOCAL | LR_PKTTERM, s, &self->reader_options); log_pipe_append(self->reader, s);
if (self->door_filename)
This will cause the log-fetch-limit() option to become effective, thus several messages are going to be fetched for every iteration, this can easily multiply performance.
Please also check if the local messages get mangled in any way, I seriously doubt that would happen, but messing with message transports always carries some risk.
Can you please send feedback on this patch? Thanks.
Sorry for the delay - I've been doing some more testing. With the patch we are still losing messages and getting the overflow messages on the console. Solaris syslogd logged 250k messages without missing any, but syslog-ng loses lots of messages - 40-50% when we are hitting it with 7000 messages/sec. At one point we saw the whole system lock up for 7 minutes. No-one could ssh to the server but those on it could carry on. It seemed that everything was waiting on syslog-ng. I ran truss on it and nothing appeared in the output for ages, then all of a sudden it started working again. Nothing was logged for these 7 minutes Truss output: -bash-3.00$ sudo truss -failed -p 1418 Base time stamp: 1203503996.5724 [ Wed Feb 20 10:39:56 GMT 2008 ] 1418/1: psargs: /opt/syslog-ng/sbin/syslog-ng 1418/1: 98890.2339 getmsg(3, 0xFFFFFFFF7FFFF630, 0xFFFFFFFF7FFFF620, 0xFFFFFFFF7FFFF5FC) = 0 1418/1: 98890.2349 time() = 1203602886 1418/1: 98890.2369 time() = 1203602886 1418/1: 98890.2394 time() = 1203602886 1418/1: 98890.2478 time() = 1203602886 1418/1: 98890.2480 time() = 1203602886 1418/1: 98890.2481 time() = 1203602886 1418/1: 98890.2482 pollsys(0x10012C0A0, 3, 0xFFFFFFFF7FFFF820, 0x00000000) = 3 1418/1: 98890.2484 write(6, " F e b 2 1 1 4 : 0 0".., 147) = 147 1418/1: 98890.2487 write(8, " F e b 2 1 1 4 : 0 0".., 147) = 147 1418/1: 98890.2489 pollsys(0x10012C0A0, 1, 0xFFFFFFFF7FFFF820, 0x00000000) = 1 1418/1: 98890.2490 getmsg(3, 0xFFFFFFFF7FFFF630, 0xFFFFFFFF7FFFF620, 0xFFFFFFFF7FFFF5FC) = 0 1418/1: 98890.2491 time() = 1203602886 1418/1: 98890.2492 time() = 1203602886 1418/1: 98890.2493 time() = 1203602886 1418/1: 98890.2494 time() = 1203602886 1418/1: 98890.2494 time() = 1203602886 1418/1: 98890.2495 time() = 1203602886 1418/1: 98890.2496 pollsys(0x10012C0A0, 3, 0xFFFFFFFF7FFFF820, 0x00000000) = 3 1418/1: 98890.2497 write(6, " F e b 2 1 1 4 : 0 0".., 163) = 163 1418/1: 98890.2499 write(8, " F e b 2 1 1 4 : 0 0".., 163) = 163 1418/1: 98890.2501 pollsys(0x10012C0A0, 1, 0xFFFFFFFF7FFFF820, 0x00000000) = 1 Regards Andy Holdaway System Administrator Nominet UK
On Thu, 2008-02-21 at 15:32 +0000, AndyH@nominet.org.uk wrote:
syslog-ng-bounces@lists.balabit.hu wrote on 21/02/2008 15:19:15:
On Wed, 2008-02-20 at 18:30 +0100, Balazs Scheidler wrote:
On Wed, 2008-02-20 at 14:32 +0000, AndyH@nominet.org.uk wrote:
When I run the syslogd as supplied with Solaris 10 then all messages
get
logged, but when I use syslog-ng then it loses messages. On a Sun V210 I see these messages
message overflow on /dev/log minor #6 -- is syslogd(1M) running? message overflow on /dev/log minor #6 -- is syslogd(1M) running? message overflow on /dev/log minor #6 -- is syslogd(1M) running? ...
diff --git a/src/afstreams.c b/src/afstreams.c index 009b074..d0a76f3 100644 --- a/src/afstreams.c +++ b/src/afstreams.c @@ -134,7 +134,7 @@ afstreams_sd_init(LogPipe *s, GlobalConfig *cfg, PersistentConfig *persist) close(fd); return FALSE; } - self->reader = log_reader_new(streams_read_new(fd), LR_LOCAL | LR_NOMREAD | LR_PKTTERM, s, &self->reader_options); + self->reader = log_reader_new(streams_read_new(fd), LR_LOCAL | LR_PKTTERM, s, &self->reader_options); log_pipe_append(self->reader, s);
if (self->door_filename)
This will cause the log-fetch-limit() option to become effective, thus several messages are going to be fetched for every iteration, this can easily multiply performance.
Please also check if the local messages get mangled in any way, I seriously doubt that would happen, but messing with message transports always carries some risk.
Can you please send feedback on this patch? Thanks.
Sorry for the delay - I've been doing some more testing. With the patch we are still losing messages and getting the overflow messages on the console.
Solaris syslogd logged 250k messages without missing any, but syslog-ng loses lots of messages - 40-50% when we are hitting it with 7000 messages/sec.
I'm missing something obvious on Solaris then. syslog-ng currently polls the /dev/log device and only reads messages from it whenever poll indicates readability. With the patch it performs several getmsg() calls for per poll iteration. I've just checked what the native syslogd does. It polls in LWP#5 then calls getmsg() and then another thread delivers the message to the system log, and another to an UDP destination. I don't think syslog-ng would be that bad, delivering the message, just because of the usage of threads. An interesting question where the lossage occurs? Is syslog-ng itself reporting message loss, or it happens in the log device? If there's a kernel warning, then probably it's the log device.
At one point we saw the whole system lock up for 7 minutes. No-one could ssh to the server but those on it could carry on. It seemed that everything was waiting on syslog-ng. I ran truss on it and nothing appeared in the output for ages, then all of a sudden it started working again. Nothing was logged for these 7 minutes
This is probably fixed by this patch (I forgot to set the streams file descriptor to nonblocking mode), and syslog-ng blocked while there was no log messages. diff --git a/src/afstreams.c b/src/afstreams.c index d0a76f3..fdf18c4 100644 --- a/src/afstreams.c +++ b/src/afstreams.c @@ -134,6 +134,7 @@ afstreams_sd_init(LogPipe *s, GlobalConfig *cfg, PersistentConfig *persist) close(fd); return FALSE; } + g_fd_set_nonblock(fd, TRUE); self->reader = log_reader_new(streams_read_new(fd), LR_LOCAL | LR_PKTTERM, s, &self->reader_options); log_pipe_append(self->reader, s);
Truss output:
-bash-3.00$ sudo truss -failed -p 1418 Base time stamp: 1203503996.5724 [ Wed Feb 20 10:39:56 GMT 2008 ] 1418/1: psargs: /opt/syslog-ng/sbin/syslog-ng 1418/1: 98890.2339 getmsg(3, 0xFFFFFFFF7FFFF630, 0xFFFFFFFF7FFFF620, 0xFFFFFFFF7FFFF5FC) = 0
I could successfully reproduce the message loss on my solaris 9 system, but I need some more time to investigate the issue. -- Bazsi
syslog-ng-bounces@lists.balabit.hu wrote on 21/02/2008 16:16:52:
At one point we saw the whole system lock up for 7 minutes. No-one could ssh to the server but those on it could carry on. It seemed that everything was waiting on syslog-ng. I ran truss on it and nothing appeared in the output for ages, then all of a sudden it started working again. Nothing was logged for these 7 minutes
This is probably fixed by this patch (I forgot to set the streams file descriptor to nonblocking mode), and syslog-ng blocked while there was no log messages.
diff --git a/src/afstreams.c b/src/afstreams.c index d0a76f3..fdf18c4 100644 --- a/src/afstreams.c +++ b/src/afstreams.c @@ -134,6 +134,7 @@ afstreams_sd_init(LogPipe *s, GlobalConfig *cfg, PersistentConfig *persist) close(fd); return FALSE; } + g_fd_set_nonblock(fd, TRUE); self->reader = log_reader_new(streams_read_new(fd), LR_LOCAL | LR_PKTTERM, s, &self->reader_options); log_pipe_append(self->reader, s);
I'll try this patch next week - I'm away until at least Wednesday.
Truss output:
-bash-3.00$ sudo truss -failed -p 1418 Base time stamp: 1203503996.5724 [ Wed Feb 20 10:39:56 GMT 2008 ] 1418/1: psargs: /opt/syslog-ng/sbin/syslog-ng 1418/1: 98890.2339 getmsg(3, 0xFFFFFFFF7FFFF630, 0xFFFFFFFF7FFFF620, 0xFFFFFFFF7FFFF5FC) = 0
I could successfully reproduce the message loss on my solaris 9 system, but I need some more time to investigate the issue.
Good news - you can reproduce the problem. I'll let you investigate. One other thing worth mentioning are these 2 warnings during compilation which may be of relevance: afstreams.c: In function `afstreams_sd_init': afstreams.c:160: warning: passing arg 1 of `door_create' from incompatible pointer type Regards Andy
On Thu, 2008-02-21 at 16:56 +0000, AndyH@nominet.org.uk wrote:
syslog-ng-bounces@lists.balabit.hu wrote on 21/02/2008 16:16:52:
At one point we saw the whole system lock up for 7 minutes. No-one could ssh to the server but those on it could carry on. It seemed that everything was waiting on syslog-ng. I ran truss on it and nothing appeared in the output for ages, then all of a sudden it started working again. Nothing was logged for these 7 minutes
Truss output:
-bash-3.00$ sudo truss -failed -p 1418 Base time stamp: 1203503996.5724 [ Wed Feb 20 10:39:56 GMT 2008 ] 1418/1: psargs: /opt/syslog-ng/sbin/syslog-ng 1418/1: 98890.2339 getmsg(3, 0xFFFFFFFF7FFFF630, 0xFFFFFFFF7FFFF620, 0xFFFFFFFF7FFFF5FC) = 0
I could successfully reproduce the message loss on my solaris 9 system, but I need some more time to investigate the issue.
Good news - you can reproduce the problem. I'll let you investigate.
During my investigations I found the followings: 1) Solaris /dev/log is not flow controlled in any way, if the buffer in the STREAMS device-head overflows, the message is gone for good and a warning is printed on the console, the same that you mentioned in one of your earlier mails. 2) The door support of syslog-ng was broken, because the door device was opened before going into the background, and doors are not inherited through forks. You can work this around by running syslog-ng with the --foreground command line option, and sending it to the background explicitly with your shell. Alternatively please apply the patch below. 3) If the door support works, clients generating messages slow somewhat down, because they invoke a door-call. This slow down then causes less messages to be dropped, but still some of it are dropped. 4) As syslog-ng is not threaded, it polls its inputs and writes its outputs from the same thread. E.g. while the output is being written, inputs are starved somewhat. This causes latency on the input side and as the STREAMS buffer is small, this latency causes more messages to be dropped, than syslogd. 5) syslogd does not lose messages if there's a single client that generates messages. If I start two instances of my simple test program, it also starts losing messages. The reason that it does not drop messages that it has a dedicated thread for polling inputs, thus the latency is smaller. On the other hand it puts all incoming messages to a queue which is not limited in size. Thus if the file write thread is slow, syslogd may consume unlimited amount of memory. 6) You can decrease the latency between getmsg() calls in syslog-ng, by * using a higher log-fetch-limit, * using throttle on the output (requires syslog-ng 2.1.x), * ensuring that your FIFO (log-fifo-size) is appropriately sized, The effects are as follows: * log-fetch-limit increases the number of getmsg() calls per poll iterations * throttle limits the number of messages written out per second, effectively limiting the time spent writing the output, So that's about it. The message loss is inherently caused by the fact that /dev/log is not flow controlled, and even worse the buffer size cannot be changed. All options I have left is to force clients to wait somewhat when they invoke the syslog door, this'd be poor man's flow-control though. This patch fixes the door initialization problem: http://git.balabit.hu/?p=bazsi/syslog-ng-2.1.git;a=commit;h=5b65710e9781203d... Once you apply this, please make sure that you use the proper path to the syslog door, which is /etc/.syslog_door for Solaris 8 and below, and /var/run/syslog_door for Solaris 9 and later.
One other thing worth mentioning are these 2 warnings during compilation which may be of relevance: afstreams.c: In function `afstreams_sd_init': afstreams.c:160: warning: passing arg 1 of `door_create' from incompatible pointer type
This is a real warning, however does not cause a problem. I'll fix that, thanks for reporting this. -- Bazsi
syslog-ng-bounces@lists.balabit.hu wrote on 24/02/2008 20:00:05:
On Thu, 2008-02-21 at 16:56 +0000, AndyH@nominet.org.uk wrote:
syslog-ng-bounces@lists.balabit.hu wrote on 21/02/2008 16:16:52:
At one point we saw the whole system lock up for 7 minutes. No-one could ssh to the server but those on it could carry on. It seemed that everything was waiting on syslog-ng. I ran truss on it and nothing appeared in the output for ages, then all of a sudden it started working again. Nothing was logged for these 7 minutes
Truss output:
-bash-3.00$ sudo truss -failed -p 1418 Base time stamp: 1203503996.5724 [ Wed Feb 20 10:39:56 GMT 2008 ] 1418/1: psargs: /opt/syslog-ng/sbin/syslog-ng 1418/1: 98890.2339 getmsg(3, 0xFFFFFFFF7FFFF630, 0xFFFFFFFF7FFFF620, 0xFFFFFFFF7FFFF5FC) = 0
I could successfully reproduce the message loss on my solaris 9
system,
but I need some more time to investigate the issue.
Good news - you can reproduce the problem. I'll let you investigate.
During my investigations I found the followings:
1) Solaris /dev/log is not flow controlled in any way, if the buffer in the STREAMS device-head overflows, the message is gone for good and a warning is printed on the console, the same that you mentioned in one of your earlier mails.
2) The door support of syslog-ng was broken, because the door device was opened before going into the background, and doors are not inherited through forks. You can work this around by running syslog-ng with the --foreground command line option, and sending it to the background explicitly with your shell. Alternatively please apply the patch below.
3) If the door support works, clients generating messages slow somewhat down, because they invoke a door-call. This slow down then causes less messages to be dropped, but still some of it are dropped.
4) As syslog-ng is not threaded, it polls its inputs and writes its outputs from the same thread. E.g. while the output is being written, inputs are starved somewhat. This causes latency on the input side and as the STREAMS buffer is small, this latency causes more messages to be dropped, than syslogd.
Can it be made threaded? Although it might still lose some messages it should lose less of them.
5) syslogd does not lose messages if there's a single client that generates messages. If I start two instances of my simple test program, it also starts losing messages. The reason that it does not drop messages that it has a dedicated thread for polling inputs, thus the latency is smaller. On the other hand it puts all incoming messages to a queue which is not limited in size. Thus if the file write thread is slow, syslogd may consume unlimited amount of memory.
6) You can decrease the latency between getmsg() calls in syslog-ng, by * using a higher log-fetch-limit, * using throttle on the output (requires syslog-ng 2.1.x), * ensuring that your FIFO (log-fifo-size) is appropriately sized,
The effects are as follows: * log-fetch-limit increases the number of getmsg() calls per poll iterations * throttle limits the number of messages written out per second, effectively limiting the time spent writing the output,
So that's about it. The message loss is inherently caused by the fact that /dev/log is not flow controlled, and even worse the buffer size cannot be changed.
All options I have left is to force clients to wait somewhat when they invoke the syslog door, this'd be poor man's flow-control though.
This patch fixes the door initialization problem:
http://git.balabit.hu/?p=bazsi/syslog-ng-2. 1.git;a=commit;h=5b65710e9781203d005e6f4bcb3f33bad4f827b6
patch fails to compile: afstreams.c:195: warning: implicit declaration of function `register_application_hook' afstreams.c:195: error: `AH_POST_DAEMONIZED' undeclared (first use in this function) afstreams.c:195: error: (Each undeclared identifier is reported only once afstreams.c:195: error: for each function it appears in.) Andy
On Fri, 2008-02-29 at 11:24 +0000, AndyH@nominet.org.uk wrote:
4) As syslog-ng is not threaded, it polls its inputs and writes its outputs from the same thread. E.g. while the output is being written, inputs are starved somewhat. This causes latency on the input side and as the STREAMS buffer is small, this latency causes more messages to be dropped, than syslogd.
Can it be made threaded? Although it might still lose some messages it should lose less of them.
I'm planning to use a threading model in syslog-ng 2.2, but in 2.0.x, it won't happen. An alternative solution is to have your application use a flow-controlled IPC mechanism, like a UNIX domain socket or a pipe.
All options I have left is to force clients to wait somewhat when they invoke the syslog door, this'd be poor man's flow-control though.
This patch fixes the door initialization problem:
http://git.balabit.hu/?p=bazsi/syslog-ng-2. 1.git;a=commit;h=5b65710e9781203d005e6f4bcb3f33bad4f827b6
patch fails to compile:
afstreams.c:195: warning: implicit declaration of function `register_application_hook' afstreams.c:195: error: `AH_POST_DAEMONIZED' undeclared (first use in this function) afstreams.c:195: error: (Each undeclared identifier is reported only once afstreams.c:195: error: for each function it appears in.)
The patch is for syslog-ng 2.1, not for 2.0, it needs further backports. -- Bazsi
syslog-ng-bounces@lists.balabit.hu wrote on 29/02/2008 17:40:16:
All options I have left is to force clients to wait somewhat when they invoke the syslog door, this'd be poor man's flow-control though.
This patch fixes the door initialization problem:
http://git.balabit.hu/?p=bazsi/syslog-ng-2. 1.git;a=commit;h=5b65710e9781203d005e6f4bcb3f33bad4f827b6
patch fails to compile:
afstreams.c:195: warning: implicit declaration of function `register_application_hook' afstreams.c:195: error: `AH_POST_DAEMONIZED' undeclared (first use in this function) afstreams.c:195: error: (Each undeclared identifier is reported only once afstreams.c:195: error: for each function it appears in.)
The patch is for syslog-ng 2.1, not for 2.0, it needs further backports.
Fails to compile on the 2.1 source: Undefined first referenced symbol in file yylex /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/../../../sparcv9/libfl.so ld: fatal: Symbol referencing errors. No output written to loggen collect2: ld returned 1 exit status gmake[3]: *** [loggen] Error 1 gmake[2]: *** [all-recursive] Error 1 gmake[1]: *** [all-recursive] Error 1 gmake: *** [all] Error 2 Andy
On Mon, 2008-03-03 at 09:50 +0000, AndyH@nominet.org.uk wrote:
syslog-ng-bounces@lists.balabit.hu wrote on 29/02/2008 17:40:16:
All options I have left is to force clients to wait somewhat when they invoke the syslog door, this'd be poor man's flow-control though.
This patch fixes the door initialization problem:
http://git.balabit.hu/?p=bazsi/syslog-ng-2. 1.git;a=commit;h=5b65710e9781203d005e6f4bcb3f33bad4f827b6
patch fails to compile:
afstreams.c:195: warning: implicit declaration of function `register_application_hook' afstreams.c:195: error: `AH_POST_DAEMONIZED' undeclared (first use in this function) afstreams.c:195: error: (Each undeclared identifier is reported only once afstreams.c:195: error: for each function it appears in.)
The patch is for syslog-ng 2.1, not for 2.0, it needs further backports.
Fails to compile on the 2.1 source:
Undefined first referenced symbol in file yylex /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/../../../sparcv9/libfl.so ld: fatal: Symbol referencing errors. No output written to loggen collect2: ld returned 1 exit status gmake[3]: *** [loggen] Error 1 gmake[2]: *** [all-recursive] Error 1 gmake[1]: *** [all-recursive] Error 1 gmake: *** [all] Error 2
I don't see how 2.1 is different in this regard from 2.0, probably the lex file was improperly generated. Can you check if cfg-lex.c is 0 bytes long? (which causes it to compile, but without any code). -- Bazsi
participants (2)
-
AndyH＠nominet.org.uk
-
Balazs Scheidler