Jeremy Utley <[EMAIL PROTECTED]> wrote in news:[EMAIL PROTECTED]:
> Randy McMurchy wrote: > >> >>This I don't understand. I thought syslog-ng was the new syslog >>daemon of choice for LFS. If it goes away, what is destined to >>replace it? >> >> >> > Gerard's post came as a shock to me as well, so I took the opprotunity > to ask him about it on IRC, since he happened to be there at the time. > Evidently some flaws have been found when syslog-ng is used in a > "production" type enviornment, placing a lot more load on it than what > most of us probably do. Archaic has more information, but to put it in > general terms, syslog-ng's handling of the logging function can > significantly delay action in some cases. I'm sure we'll here more on > it soon. > > -J- > The issues are: ====== Performance: The syslog-ng package currently doesn't support asynchronous writes - therefore in large scale syslog environments under disk load, the daemon can get behind, and even drop packets. Sysklogd can batch writes (using the - prefix to the logfile name) and thus *can* perform better under load. That said, a system that has that large a syslog load is likely to have a dedicated syslog server, which should mitigate the problem mentioned. Security: The syslog-ng package has a built in option to create a chroot, and use a dedicated user\group combination. Unfortunately, this does *not* appear to work when reading /proc/kmsg (the kernel message pipe). Not done exhaustive tests, but the initial reading appears to be that this functionality is somewhat broken. Sysklogd has patches that implement proper privielge dropping thats works fine. Simplicity: No external libraries are needed to build sysklogd - one less package (whether libol or glob) to build\test\maintain. And the primary reason for switching was the lack of a maintainer for sysklogd, which is now fixed. ===== Overall, the advantages of syslog-ng (tcp syslog forwarding, extensive filtering capabilities) are more likely to be used in specialist environments, rather than the "base + some functionality" build that LFS aims to be. My vote would be to remove syslong-ng and use sysklogd again, even though if that happens I would personally re-implement by build scripts to use syslog-ng instead (since my personal usage of LFS requires the filtering capability in syslog-ng). -- - Steve Crosby -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
