> btw do you know if there's anything that would be needed to change if > syslog-ng were to become a real drop-in replacement for syslogd? >
1. Fix syslog-ng config (apart from stupid formatting bug /dev/log seems to be DGRAM not STREAM contrary to syslog-ng readme). 2. Add proper logrotate to syslog-ng 3. Split sysklogd into klogd and syslogd proper so that you could replace syslogd part with alternative implementation. You can run syslog-ng without klogd but then you need /proc/kmsg i.e. it won't work if /proc is not mounted. 4. Add syslog-ng support to msec. The reason for a split is, logrotate for syslogd and syslog-ng refer to the same files which means logs are rotated twice. What I had in mind is to make syslog-ng conflict with syslogd. Alternative is (assuming syslog-ng is adopted) to just check which one is currently running and prime it. Fredl, do you have any plans to add support for external modules? It would be ideal case - syslog-ng comes with own msec module to avoid rewriting it every time. Currently I have fixed RPM (based on syslog-ng 1.5.17); if there is any interest I can upload it but I do not know what to do with sources - one file is defined as extra source and AFAIK sources are not entered in CVS when I upload RPM? Also it does not contain logrotate support for above reasons. > And the sysklogd maintainer is .... Warly. you can ask him for the final > decision :-) > So far syslog-ng seems to work here and it allows _far_ better control over where your logs go. It has some problems in interaction with klogd but I bet it is solvable. -andrej
