Hi,
Thanks! That seemed to do the trick. It appears now that each log entry is being duplicated, but I can live with that for the time being. Would that be the result of an extra line I have in there somewhere, or do I need to look forther at the src/destination directives?
Your log definitions have a lot of duplicate entries as you're defining syslog-like severity ranges (like f_info is an info..emerg range filter, ans do on). So when a message with the err priority arrives then f_info, f_notice, f_warning and f_err will match. When I convert a syslogd conffile to syslog-ng, I usually create a matrix which facility/priority will logged to which destination. Something like this: emerg| alert| crit | err | warn |notice| info | debug kernel| ME mail | ME MA ... (where MA means /var/log/mail.log and ME is /var/log/messages) After this I set up the filters/ destinations, and use this matrix to create the configuration: # kernel.debug /var/log/messages log { source(s_local); filter(f_kernel); filter(f_debug); destination(d_messages); flags(final); }; # mail.crit /var/log/mail.log /var/log/messages log { source(s_local); filter(f_mail); filter(f_crit); destination(d_messages); destination(d_maillog); flags(final); }; # mail.info /var/log/mail.log log { source(s_local); filter(f_mail); filter(f_info); destination(d_maillog); flags(final); }; # don't log mail.debug anywhere else log { source(s_local); filter(f_mail); flags(final); }; Usually I also test the config with a small script which sends logs with every possible facility/severity combinations to check whether the logs end up in the correct destination or not. Of course this isn't the easiest way to configure syslog-ng, just the way I do it :) regards, Sandor -------------------------------------------------------- NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.