On Tue, Mar 05, 2002 at 05:15:11PM +0100, p@netoides.com wrote:
Hello syslog-ng developers.
We are using your wonderful syslog-ng to receive some big message chunks. We noticed that syslog-ng drops bytes above 1Kb when using UDP. So, we changed to TCP and, to our surprise, we found that syslog-ng splits messages in chunks of 1Kb (approx).
Is it possible to configure syslog-ng so that each tcp message goes to only one line? If this is not possible, what about modifing syslog-ng to add this capability? We can contribute development effort.
after applying the following patch, you can change the maximum line length of syslog-ng by changing the MAX_LOG_LINE constant in syslog-ng.h (currently 2048 bytes) Index: sources.c =================================================================== RCS file: /var/cvs/syslog-ng/src/sources.c,v retrieving revision 1.30 diff -u -r1.30 sources.c --- sources.c 2002/02/28 13:05:37 1.30 +++ sources.c 2002/03/05 18:38:35 @@ -49,7 +49,7 @@ (vars (dgram simple UINT32) (pos simple UINT32) - (buffer array UINT8 MAX_LINE) + (buffer array UINT8 MAX_LOG_LINE) (next object log_handler))) */ @@ -81,11 +81,11 @@ size_t salen = sizeof(sabuf); if (!closure->dgram) { - n = A_READ(read, MAX_LINE - closure->pos, closure->buffer + closure->pos); + n = A_READ(read, MAX_LOG_LINE - closure->pos, closure->buffer + closure->pos); salen = 0; } else - n = A_RECV(read, MAX_LINE - closure->pos, closure->buffer + closure->pos, (abstract_addr *) &sabuf, &salen); + n = A_RECV(read, MAX_LOG_LINE - closure->pos, closure->buffer + closure->pos, (abstract_addr *) &sabuf, &salen); switch(n) { case 0: -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
Balazs Scheidler wrote:
On Tue, Mar 05, 2002 at 05:15:11PM +0100, p@netoides.com wrote:
Hello syslog-ng developers.
We are using your wonderful syslog-ng to receive some big message chunks. We noticed that syslog-ng drops bytes above 1Kb when using UDP. So, we changed to TCP and, to our surprise, we found that syslog-ng splits messages in chunks of 1Kb (approx).
Is it possible to configure syslog-ng so that each tcp message goes to only one line? If this is not possible, what about modifing syslog-ng to add this capability? We can contribute development effort.
after applying the following patch, you can change the maximum line length of syslog-ng by changing the MAX_LOG_LINE constant in syslog-ng.h (currently 2048 bytes)
Thanks. Incidentally, i have to remove the quote in (define-syntax let-and (syntax-rules '() ((let-and (expr) clause clauses ...) in make_class to be able to recompile. I am using scsh 0.6.1. Thanks again, pedro.
p@netoides.com writes:
Incidentally, i have to remove the quote in
(define-syntax let-and (syntax-rules '() ((let-and (expr) clause clauses ...)
in make_class to be able to recompile. I am using scsh 0.6.1.
That's the same problem I had (with scsh 0.6.0) trying to run make_class. make_class now works for me when called standalone, which it didn't previously. But I still have trouble rebuilding the source: gmake all-recursive gmake[1]: Entering directory `/devel/build/syslog-ng-1.5.14/src' Making all in . gmake[2]: Entering directory `/devel/build/syslog-ng-1.5.14/src' ./make_class <afinet.c >afinet.c.xT Processing class afinet_source Processing class afinet_dest gmake[2]: *** [afinet.c.x] Error 123 So make_class is returning exit status 123, which isn't what the Makefile wants. I've been editing my Makefile, did I accidentally delete something? Adding an "|| true" to the line where MAKE_CLASS is called seems to work, since the Makefile does check for the presence of a non-zero foo.c.x. -- Ed
Has anyone else wanted to have the equivalent of #include <file> in syslog-ng's configuration file? Are there any issues with doing this that have been discussed previously?
Hi, I've taken a different more flexible approach (based on what's become common practice in the Debian GNU/Linux distribution: I've created a directory called 'syslog-ng.d' and in that directory I've put syslog-ng configuration file sniplets. The basis set consists of the following: - one containing a comment header - one for global options - one for syslog-ng itself (using internal()) - one for using localhost as source - one containing a comment trailer Each sniplet has a name of '<digit><digit><sniplet nmae>' to enforce a certain order. In the syslog-ng start-stop script I then do cat syslog-ng.d/* >syslog-ng.conf upon a start and reload. Any application that has logging needs just puts the appropriate configuration sniplet in the syslog-ng.d directory and does a reload of syslog-ng. Updating a sniplet goes similar. Thanks, Ardo Ed Ravin wrote:
Has anyone else wanted to have the equivalent of #include <file> in syslog-ng's configuration file? Are there any issues with doing this that have been discussed previously?
_______________________________________________ syslog-ng maillist - syslog-ng@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/syslog-ng
Ardo van Rangelrooij writes:
I've taken a different more flexible approach (based on what's become common practice in the Debian GNU/Linux distribution: I've created a directory called 'syslog-ng.d' [...]
Each sniplet has a name of '<digit><digit><sniplet nmae>' [...] cat syslog-ng.d/* >syslog-ng.conf upon a start and reload.
It's nice to be flexible, but I think the init.d paradigm, which relies on tricks of alphabetical filename sorting to enforce order at the expense of readability and managability, should be retired, not expanded. The joy of syslog-ng is that it has a clean, readable, and predictable configuration file. An extension for reading in include files would hopefully preserve those attributes.
Ed Ravin wrote:
Ardo van Rangelrooij writes:
I've taken a different more flexible approach (based on what's become common practice in the Debian GNU/Linux distribution: I've created a directory called 'syslog-ng.d' [...]
Each sniplet has a name of '<digit><digit><sniplet nmae>' [...] cat syslog-ng.d/* >syslog-ng.conf upon a start and reload.
It's nice to be flexible, but I think the init.d paradigm, which relies on tricks of alphabetical filename sorting to enforce order at the expense of readability and managability, should be retired, not expanded.
If you're talking about managability the method I presented is favourable above changing a file just to add an #include statement. I prefer not to have tools changing configuration files during package install/removal, unless there's a wrapper available that does that on behave of the package (like using `adduser` instead of accessing /etc/passwd directly).
The joy of syslog-ng is that it has a clean, readable, and predictable configuration file. An extension for reading in include files would hopefully preserve those attributes.
You've lost me. If you use #include statetements your syslog-ng.conf could look like this: #include header #include global_options #include syslog-ng_internal #include source_localhost #include app_A_logging #include app_B_logging Wow, I'm impressed with the readability we just achieved. If I do an `ls' in my syslog-ng.d directory I see more or less the same. No matter which partitioning scheme we want to use, it all comes down to a proper organization of the configuration and keeping things together that belongs together. I'm also in favour of adding functionality to syslog-ng which is already available in cpp, m4 and other similar tools. I'm in favour of the UNIX style of small tools working together each doing it's own dedicated task. And how far do you want to go? Nested include's? Why then not simply use cpp as a preprocessor? Thanks, Ardo
Hi!
It's nice to be flexible, but I think the init.d paradigm, which relies on tricks of alphabetical filename sorting to enforce order at the expense of readability and managability, should be retired, not expanded. Agreed.
If you're talking about managability the method I presented is favourable above changing a file just to add an #include statement. I prefer not to have tools changing configuration files during package install/removal, unless there's a wrapper available that does that on behave of the package (like using `adduser` instead of accessing /etc/passwd directly). Agreed, too.
I personnally don't like the Idea of having my configuration files written for me by a script that I have to invoke everytime I change something. (And regenerating the configuration automatically whenever I (re)start a service is not what I call very efficient...) So, what about something like "include /etc/syslog-ng.d/*.conf" ? Greetings Gert
Gert Menke wrote:
Hi!
It's nice to be flexible, but I think the init.d paradigm, which relies on tricks of alphabetical filename sorting to enforce order at the expense of readability and managability, should be retired, not expanded.
Agreed.
If you're talking about managability the method I presented is favourable above changing a file just to add an #include statement. I prefer not to have tools changing configuration files during package install/removal, unless there's a wrapper available that does that on behave of the package (like using `adduser` instead of accessing /etc/passwd directly).
Agreed, too.
I personnally don't like the Idea of having my configuration files written for me by a script that I have to invoke everytime I change something. (And regenerating the configuration automatically whenever I (re)start a service is not what I call very efficient...)
So, what about something like "include /etc/syslog-ng.d/*.conf" ?
Ok, I like that. But how do we guarantee a certain order? Even a simple `ls` lists the files dependent on the locale. Thanks, Ardo
I haven't noticed any instances where the order of the conf file has mattered much to the functionality of syslog-ng. Perhaps I've missed something? -- Allen
Ok, I like that. But how do we guarantee a certain order? Even a simple `ls` lists the files dependent on the locale.
Thanks, Ardo
_______________________________________________ syslog-ng maillist - syslog-ng@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/syslog-ng
Hi!
Ok, I like that. But how do we guarantee a certain order? Even a simple `ls` lists the files dependent on the locale.
I am not sure if a guaranteed order is necessary at all, but if someone really needs it, I suggest that syslog-ng should always use the C-locale ordering. But making a few groups of logfile rules and including them as follows: include ("/etc/syslog-ng.d/1-*"); # stuff that has to be at the # beginning for some reason include ("/etc/syslog-ng.d/2-*"); # main include ("/etc/syslog-ng.d/3-*"); # catch-all rules for everything # that didn't match above should be sufficient for almost everyone, I guess... Greetings Gert
participants (6)
-
Allen Bettilyon
-
Ardo van Rangelrooij
-
Balazs Scheidler
-
Ed Ravin
-
Gert Menke
-
p＠netoides.com