Many thanks to Stephen Frost and Balazs for the useful information and suggestions regarding PIX syslogging. Having had a slightly deeper read of the latest src tree, I'd like to just make a few suggestions and comments. Several of the options available have Default Settings in their relevant subsection of the HTML tree within: /usr/src/syslog-ng/syslog-ng-1.5.19/doc/sgml/syslog-ng.html However, several options don't have defaults listed therein. Perhaps the next round of documentation updates could double check that all defaults are fully listed in the html pages. The Main HTML Doc Pages at http://www.balabit.hu/static/syslog-ng/reference/book1.html contain no reference to recent dns_cache options - even though this option appears to have been available for about 18 months. As I think several others have mentioned on the list, it would seem reasonable for a more up to date copy of the html pages to be glued up onto the website. The syslog-ng man pages explicitly state that destinations are closed and re-opened on SIGHUP, as per dear-old syslogd's behaviour. There have been references on the mailing list and the FAQs to the corresponding close / re-open of sources, but no explicit statement in the docs. Could I request that an explicit statement of source file descriptor open/close behaviour on SIGHUP be added to the docs/FAQ, please. Others on the list have noted that closing /dev/log on HUP causes certain programs grief - notably sendmail which requires a further HUP to itself to properly heal the broken syslog file descriptor. If syslog-ng does indeed close descriptors on HUP, can we please have an option to explicitly keep certain descriptors open on HUP. ( The docs suggest this may already be possible for TCP sockets, and Unix SOCK_STREAM sockets, but not Unix SOCK_DGRAM sockets ). See ensuing paragraphs for why I'd like the option to be available on Unix SOCK_DGRAM. In all the syslog-ng docs, Linux platforms are documented as having a default log listener socket of /dev/log SOCK_STREAM. However, the most recent RedHat sysklogd RPMs open /dev/log in SOCK_DGRAM mode. I believe this was done as part of a security patch to avoid a potential DoS attack against the stream socket. To the best of my recollection, this behaviour changed about a year ago. This seems to bring RedHat - at least - in line with other BSD variants. glibc openlog() call on RedHat opens SOCK_DGRAM first, falling back to SOCK_STREAM if that fails. Hence RedHat's glibc still supports either socket type, and hence syslog-ng's documented Linux defaults still work. Likewise, Perl's Syslog.pm module calls SOCK_DGRAM first falling back to SOCK_STREAM. Sometime during the change from kernel 2.0 to 2.2 I believe, the Unix DGRAM socket type behaviour was adjusted to blocking ( this assumption purely based on the perceived behaviour of sysklogd ). Thus it should be impossible to drop a message across a Unix DGRAM socket , as compared with the ease of such a message being dropped across an UDP DGRAM socket when the system is really busy. Hence the change from SOCK_STREAM to SOCK_DGRAM within sysklogd should not make the system more prone to dropping locally logged messages, as might have been the case with earlier kernels? Given all of the above, is it reasonable to change the preferred documented socket type from STREAM to DGRAM on /dev/log for syslog-ng on Linux? "logger-ng" - I believe others may also have asked for this - does such a thing exist? to allow one to create test messages and the like over TCP etc etc etc. Sys::Syslog-NG.pm ?? does such a thing exist to support Perl Syslogging over TCP and suchlike? Ted Rule, Flextech Television *************************************************************************************************** This E-mail message, including any attachments, is intended only for the person or entity to which it is addressed, and may contain confidential information. If you are not the intended recipient, any review, retransmission, disclosure, copying, modification or other use of this E-mail message or attachments is strictly forbidden. If you have received this E-mail message in error, please contact the author and delete the message and any attachments from your computer. You are also advised that the views and opinions expressed in this E-mail message and any attachments are the author's own, and may not reflect the views and opinions of FLEXTECH Television Limited. ***************************************************************************************************