[syslog-ng] Need help upgrading from 2.0.4 to 3.2.5

Balazs Scheidler bazsi77 at gmail.com
Thu Feb 7 06:56:03 CET 2013


----- Original message -----
> We have moved from OEL4 to OEL6 and I need help moving the 2.0.4
> functionality to the new version of syslog-ng. I am having issues with
> our custom application logging which has very large messages and long
> stack traces. I am not seeing the same behavior in 3.2.5. In 3.2.5 I am
> seeing truncated messages and the first line of the stack trace is being
> logged to the correct facility local5 while the rest of the stack trace
> is being logged to /var/log/messages. Also the stack trace is not being
> preserved anymore. Instead every line is being treated as a new line and
> a new syslog entry. Our custom app logging is not the best and contains
> carriage returns which used to be stripped by 2.0.4 but that is not
> happening now. Can these behaviors from 2.0.4 be preserved in 3.2.5?
> 
> Any suggestions are appreciated.
> 
> Here is what I am trying to work with in 3.2.5
> 
> options {
>                 flush_lines (0);
>                 time_reopen (10);
>                 log_fifo_size (1000);
>                 long_hostnames (off);
>                 use_dns (yes);
>                 use_fqdn (no);
>                 create_dirs (no);
>                 keep_hostname (yes);
>                 stats_freq (50000);
>                 log_msg_size(8192);
> };
> 
> source s_sys {
>                 pipe("/proc/kmsg" log_prefix("kernel: "));
>                 unix-dgram ("/dev/log" flags("no-multi-line"));
> 

this should work fine, as long as your application really submits through /dev/log.

can you run syslog-ng in foreground/debug mode and see what it prints as 'Incoming message' from your application?

if that's not feasible, you can alsways use strace for the same purpose (strace the app or syslog-ng) but make sure you use large string size option (-s 4096 for example) so that a longer part of the message is displayed:

# strace -o log.txt -s 4096 -p <pidofsyslogng>

3.2 is old now, so my memory doesn't stretch that far back in time, but the source you wrote should be ok. it would be nice to find out the root cause with that version, then I can check if we fixed it in the past or if it's not syslog-ng that's buggy.

Cheers

                internal();
>                 udp(ip(127.0.0.1) port(514));
> };
> 
> destination d_cons { file("/dev/console"); };
> destination d_mesg { file("/var/log/messages" perm(0644)); };
> destination d_mesgr { udp("remote syslog server" port(514)); };
> destination d_auth { file("/var/log/secure"); };
> destination d_authr { udp("remote syslog server" port(514)); };
> destination d_mail { file("/var/log/maillog" flush_lines(10)); };
> destination d_spol { file("/var/log/spooler"); };
> destination d_boot { file("/var/log/boot.log"); };
> destination d_cron { file("/var/log/cron"); };
> destination d_cronr { udp("remote syslog server" port(514)); };
> destination d_cust_app { file("/var/log/cust_app.log" owner("test")
> group("test") perm(0644)); };
> destination d_kern { file("/var/log/kern"); };
> destination d_mlal { usertty("*"); };
> 
> filter f_filter1     { facility(kern); };
> filter f_filter2     { level(info..emerg) and
>                                           not (facility(mail)
>                                               or facility(authpriv)
>                                               or facility(cron)
>                                               or facility(local5)); };
> filter f_filter3     { facility(authpriv); };
> filter f_filter4     { facility(mail); };
> filter f_filter5     { level(emerg); };
> filter f_filter6     { facility(uucp) or
>                                           (facility(news)
>                                               and level(crit..emerg)); };
> filter f_filter7     { facility(local7); };
> filter f_filter9     { facility(local5); };
> filter f_filter8     { facility(cron); };
> 
> log { source(s_sys); filter(f_filter1); destination(d_cons); };
> log { source(s_sys); filter(f_filter1); destination(d_kern); };
> log { source(s_sys); filter(f_filter2); destination(d_mesg); };
> log { source(s_sys); filter(f_filter2); destination(d_mesgr); };
> log { source(s_sys); filter(f_filter3); destination(d_auth); };
> log { source(s_sys); filter(f_filter3); destination(d_authr); };
> log { source(s_sys); filter(f_filter4); destination(d_mail); };
> log { source(s_sys); filter(f_filter5); destination(d_mlal); };
> log { source(s_sys); filter(f_filter6); destination(d_spol); };
> log { source(s_sys); filter(f_filter7); destination(d_boot); };
> log { source(s_sys); filter(f_filter8); destination(d_cron); };
> log { source(s_sys); filter(f_filter8); destination(d_cronr); };
> log { source(s_sys); filter(f_filter9); destination(d_cust_app); };

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.balabit.hu/pipermail/syslog-ng/attachments/20130207/ef6dda4b/attachment.htm 


More information about the syslog-ng mailing list