Hi all, I think syslog-ng should probably be brought into Fedora Core to replace syslogd.
In order to achieve that goal I've been told that making a good case for why syslog-ng is beneficial to the distro needs to be added to this bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=113858
I'll be adding my own comments shortly, but if any of you have comments to that regard please add them.
Thanks -sv
On Fri, 20 Aug 2004, seth vidal wrote:
Hi all, I think syslog-ng should probably be brought into Fedora Core to replace syslogd.
In order to achieve that goal I've been told that making a good case for why syslog-ng is beneficial to the distro needs to be added to this bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=113858
I'll be adding my own comments shortly, but if any of you have comments to that regard please add them.
I've added the below comment, but since I get the feeling a nice big flamewar is coming anyway (it's been what.. 2, 3 hours since the last one?) I'll be happy to start it.
Oh god. Please no! The questions from my users will never ever ever end.
If you want a nicer syslog daemon, how about metalog[1] or at least something with a config syntax that doesn't require a PhD in Physics to understand?
[1] - http://metalog.sourceforge.net/
-n
On Fri, 2004-08-20 at 23:16, nathan r. hruby wrote:
On Fri, 20 Aug 2004, seth vidal wrote: If you want a nicer syslog daemon, how about metalog[1] or at least something with a config syntax that doesn't require a PhD in Physics to understand?
There're other benefits among the easy configuration.
Metalog is buffered and it's really low resurce consuming. I've used it with gentoo (it's the recommended logger for gentoo with syslog-ng) and worked like a charm.
ITOH it's buffered architecture make it really bad for developers or kernel debuggers as log messages does not arise instantly, but when the buffer is big enought to write it out (the buffering can be disabled).
I'm almost sure it can confuse users/developers.
IMHO it's the best logger for low end machines.
On Sat, 21 Aug 2004 17:49, Iago Rubio iago.rubio@hispalinux.es wrote:
ITOH it's buffered architecture make it really bad for developers or kernel debuggers as log messages does not arise instantly, but when the buffer is big enought to write it out (the buffering can be disabled).
How is this different from the regular syslogd?
I have configured lots of machines with the "-" option on all log files to use buffering and reduce IO load. I haven't found any great problems with that, often a kernel bug will break even non-buffered disk IO...
On Sat, 2004-08-21 at 13:30, Russell Coker wrote:
On Sat, 21 Aug 2004 17:49, Iago Rubio iago.rubio@hispalinux.es wrote:
ITOH it's buffered architecture make it really bad for developers or kernel debuggers as log messages does not arise instantly, but when the buffer is big enought to write it out (the buffering can be disabled).
How is this different from the regular syslogd?
Well, syslogd will flush out any input "instantly", so it's easier to get the log message than with buffered output, where log messages will be flushed out depending on it's size.
I have configured lots of machines with the "-" option on all log files to use buffering and reduce IO load. I haven't found any great problems with that, often a kernel bug will break even non-buffered disk IO...
I agree with you.
I'm just pointing that some users and developers will find surprising that log messages does not appears instantly. I'm sure someone will be fooled when using `watch tail /var/log/messages` to debug a daemon - for the buffered IO, and the lack of /var/log/messages in metalog.
In fact the buffering IO of metalog is not a problem at all, when you know that `killall -USR1 metalog` will turn buffering off, and `killall -USR2 metalog` will turn it on.
I'm not advocating against metalog. I've got it working in my laptop and I'm really happy.
I was just pointing to some issues that will appear, if someone turns metalog the default system logger without warning users.
I'd love to see metalog in Fedora, even to see it as the default syslog daemon.
Any of both, metalog or syslog-ng, could be great replacements for syslogd, and can be used in production with confidence.
On Sun, 22 Aug 2004 03:21, Iago Rubio iago.rubio@hispalinux.es wrote:
On Sat, 2004-08-21 at 13:30, Russell Coker wrote:
On Sat, 21 Aug 2004 17:49, Iago Rubio iago.rubio@hispalinux.es wrote:
ITOH it's buffered architecture make it really bad for developers or kernel debuggers as log messages does not arise instantly, but when the buffer is big enought to write it out (the buffering can be disabled).
How is this different from the regular syslogd?
Well, syslogd will flush out any input "instantly", so it's easier to
Not if you use option "-".
I have configured lots of machines with the "-" option on all log files to use buffering and reduce IO load. I haven't found any great problems with that, often a kernel bug will break even non-buffered disk IO...
I agree with you.
I'm just pointing that some users and developers will find surprising that log messages does not appears instantly. I'm sure someone will be
Why will they be surprised? We have two syslog programs which can be configured to buffer log data or write it synchronously. Making them both have the same default in this regard is trivial.
The choice of which syslogd to use is independent of the choice of whether to use buffering.
FWIW I think that we should buffer all logs other than auth.log and kern.log (which would only have the higher priority kernel messages to have a better chance of getting Oops messages before things really die).
In most cases synchronous writes for logs just reduces performance for no benefit.
On Sun, Aug 22, 2004 at 10:12:00PM +1000, Russell Coker wrote:
In most cases synchronous writes for logs just reduces performance for no benefit.
(I didn't check whether it does this already.) Wouldn't it be possible to speed up synchronous syslogging with something like this:
while (1) { logbuf = blocking_read(syslog_socket); while (space_left(logbuf) && data_available(syslog_socket)) logbuf .= nonblocking_read(syslog_socket);
write_to_log_files(logbuf); }
That way, if you get a burst of log messages, the first sync write would write out just a single line, and all the next writes would write out everything that accumulated in the buffer so far in one single sync write.
That way, you still get sync behaviour, but without the whole-disk-roundtrip-per-log-line overhead.
Just a thought.
cheers, Lennert
On Sun, 22 Aug 2004 22:19, Lennert Buytenhek buytenh@wantstofly.org wrote:
On Sun, Aug 22, 2004 at 10:12:00PM +1000, Russell Coker wrote:
In most cases synchronous writes for logs just reduces performance for no benefit.
(I didn't check whether it does this already.) Wouldn't it be possible to speed up synchronous syslogging with something like this:
That way, if you get a burst of log messages, the first sync write would write out just a single line, and all the next writes would write out everything that accumulated in the buffer so far in one single sync write.
Your pseudo-code didn't clearly explain your intent.
That way, you still get sync behaviour, but without the whole-disk-roundtrip-per-log-line overhead.
Usually when there's a lot of logging the performance of the syslogd itself is not the issue. The problem is that synchronous writes kill file system performance and interfere with the performance of other programs in the system. Synchronous syslogd operation can reduce performance of a server that's bottlenecked by disk writes by 20% or more. For a serious mail server you don't want the mail facility log entries to go to a synchronous file. The synchronous writes to the mail queue and for mail delivery hurt enough.
If the performance of the syslogd itself is the issue then you have no option but to turn off synchronous writes. For this situation it would be good if there was an option to select whether the daemon should write directly but not synchronously or whether it should wait for page-sized buffers (IE use fwrite()).
On Sun, Aug 22, 2004 at 11:36:57PM +1000, Russell Coker wrote:
In most cases synchronous writes for logs just reduces performance for no benefit.
(I didn't check whether it does this already.) Wouldn't it be possible to speed up synchronous syslogging with something like this:
That way, if you get a burst of log messages, the first sync write would write out just a single line, and all the next writes would write out everything that accumulated in the buffer so far in one single sync write.
Your pseudo-code didn't clearly explain your intent.
Oh. Sorry. The idea was that "if you're going to do a sync write anyway, why not write out all waiting messages at the same time, instead of doing a sync write for each and every one of them even if the queue is a hundred messages long."
That way, you still get sync behaviour, but without the whole-disk-roundtrip-per-log-line overhead.
Usually when there's a lot of logging the performance of the syslogd itself is not the issue. The problem is that synchronous writes kill file system performance and interfere with the performance of other programs in the system.
The approach I suggested would still have it make do sync writes, but far less of them when there is a log burst compared to the old method.
But yeah, it all comes down to "how important are your log messages to you?"
--L
I've added the below comment, but since I get the feeling a nice big flamewar is coming anyway (it's been what.. 2, 3 hours since the last one?) I'll be happy to start it.
Oh god. Please no! The questions from my users will never ever ever end.
What did you do when things switched from apache 1.3 to apache 2? The config files changed there, too.
You couldn't do that migration w/o munging files.
moreover, how many users REALLY touch their syslogd config files? I'd bet it's something like 2% who ever touch them. Most just rely on the defaults to dtrt.
If you want a nicer syslog daemon, how about metalog[1] or at least something with a config syntax that doesn't require a PhD in Physics to understand?
metalog hasn't been updated or maintained in over a year. A stable release in over 2 years.
Syslog-ng is being actively maintained.
-sv
On Sun, 22 Aug 2004, seth vidal wrote:
I've added the below comment, but since I get the feeling a nice big flamewar is coming anyway (it's been what.. 2, 3 hours since the last one?) I'll be happy to start it.
Oh god. Please no! The questions from my users will never ever ever end.
What did you do when things switched from apache 1.3 to apache 2? The config files changed there, too.
You couldn't do that migration w/o munging files.
Actually, it's been fairly easy :) Most of the config options remained the same and many of the ones that changed I don't use or were fairly trivial. My configs were easy to migrate, and most of the others I've seen / inherited are so horribly written they needed a rewrite before they could even get ported in the first place :)
I think the analogy is not really a apples->apples one though, as the syntax, format, and most of the directives were the same or similar. The syslog -> syslog-ng config formats in no way resemble each other other than they use the same general vocabulary for describing things.
moreover, how many users REALLY touch their syslogd config files? I'd bet it's something like 2% who ever touch them. Most just rely on the defaults to dtrt.
Perhaps. I still think it's overkill. In my dream of dreams there'd be a small sysklogd that was easy to configure and fairly secure that allowed syslog-clients to work well and then use something like syslog-ng on the backend.
Again, I could be placated with a redhat-config-syslog that made it easy to satisfy 80% of the syslog needs for users new to Unix/Linux how the admin who just doesn't want to bother with YACS. My point is that I think it's more than 2% altering configs and syslog-ng's config syntax is dense enough that there's going to be confusion. Some additional thought, energy and effort should go into the decisions, as opposed to just making the switch and forcing people to figure it out.
I don't think that *you* were advocating such a process, but it seems like that seems to be the going trend.
If you want a nicer syslog daemon, how about metalog[1] or at least something with a config syntax that doesn't require a PhD in Physics to understand?
metalog hasn't been updated or maintained in over a year. A stable release in over 2 years.
Syslog-ng is being actively maintained.
I brought metalog up as a sample other logger. I personally could care less what package it is so long as it is easy to configure.
-n
I think syslog-ng should probably be brought into Fedora Core to replace syslogd.
How about bringing it in as an alternate? For example, there 5-6 different mail programs, 3 smpt deamons, at least 2 http deamons, and a couple news deamons already in the distribution. The people that want to try out the new daemon can do so and if they don't get hacked, other people might try it too. I'd vote for making it available, but not the default.
But let's also consider this. According to freshmeat, it was last updated in March 2003. Is it being maintained? Or is it done?
I would advocate moving slowly for security related items. Logging is a cornerstone of security.
-Steve Grubb
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
How about bringing it in as an alternate? For example, there 5-6 different mail programs, 3 smpt deamons, at least 2 http deamons, and a couple news deamons already in the distribution. The people that want to try out the new daemon can do so and if they don't get hacked, other people might try it too. I'd vote for making it available, but not the default.
But let's also consider this. According to freshmeat, it was last updated in March 2003. Is it being maintained? Or is it done?
http://www.balabit.com/products/syslog_ng/upgrades.bbq
last release was 15 days ago.
I would advocate moving slowly for security related items. Logging is a cornerstone of security.
Which is why I advocate bringing in syslog-ng, if not as a replacement at least as an option for a syslog daemon.
syslog-ng supports regexs on logs, splitting on hostname, separate scripts per instance, tcp, alternate ports, stunnel wrapping of the whole daemon.
it's head and shoulders above syslogd and I can personally say I've been running it on our central loghost for > 4 yrs now w/o a problem.
-sv
On Fri, 20 Aug 2004, seth vidal wrote:
Which is why I advocate bringing in syslog-ng, if not as a replacement at least as an option for a syslog daemon.
I would be ok with it as an alternative or in Extras.
syslog-ng supports regexs on logs, splitting on hostname, separate scripts per instance, tcp, alternate ports, stunnel wrapping of the whole daemon.
Yes, it certainly rocks. However, the config syntax is decidedly *not* user friendly. I have seen experienced admins goof up plain 'ol sysklogd config syntax and I can see their mind boggle at syslog-ng's syntax, much less some newbie or fancy-pants DBA. I think it'd be a large support load and awful harsh transition for a good number of people, sysklogd currently mimics the general feel of syslog.conf on a good number of other platforms....
My suggestions (in no order of importance): - ship syslog-ng as an alternative or in extras - ship a syslog-ng config editor that makes things easy for the 80% of the people in the world who aren't using central syslogging. - Find / support / ship an alternate secure and robust syslogd that is easy on the end user (I offered metalog as an example, but there many others too) - Write a new *client* end syslogd that has all the features a client would need but is still small and easy to configure for local logging, allowing people to use something with higher power on central servers. (this, I think, as an excellent side project should someone want to cover it because there's nothing like this presently)
it's head and shoulders above syslogd and I can personally say I've been running it on our central loghost for > 4 yrs now w/o a problem.
Right, but that's the problem. Not everyone (or every box) is running as a syslog server, which is where most of syslog-ng's power shines. For the end user or small shop this is overload.
Am I saying this will never work? No. But the transition isn't as easy as replacing X with Y for a lot of people. Thought needs to go into the transition and end product as well as security.
-n
On Fri, 20 Aug 2004, seth vidal wrote:
How about bringing it in as an alternate? For example, there 5-6 different mail programs, 3 smpt deamons, at least 2 http deamons, and a couple news deamons already in the distribution. The people that want to try out the new daemon can do so and if they don't get hacked, other people might try it too. I'd vote for making it available, but not the default.
Choices are always good. :-)
But let's also consider this. According to freshmeat, it was last updated in March 2003. Is it being maintained? Or is it done?
Does someone have rpms or a specfile for this?? It has been on my todo list for some time.
Tom
But let's also consider this. According to freshmeat, it was last updated in March 2003. Is it being maintained? Or is it done?
Does someone have rpms or a specfile for this?? It has been on my todo list for some time.
http://bugzilla.fedora.us/show_bug.cgi?id=1332
-sv
seth vidal wrote:
But let's also consider this. According to freshmeat, it was last updated in March 2003. Is it being maintained? Or is it done?
Does someone have rpms or a specfile for this?? It has been on my todo list for some time.
Updated the SRPMS a couple of days ago. The Fedora.us bugzilla entries are the following:
libol 0.3.14 (update): https://bugzilla.fedora.us/show_bug.cgi?id=2014
syslog-ng 1.6.5 (and 1.6.2): https://bugzilla.fedora.us/show_bug.cgi?id=1332
libol 0.3.13 (already in fedora.us mirrors): http://bugzilla.fedora.us/show_bug.cgi?id=1331
Reviews are welcome ;)
Regards, jpo
On Fri, 20 Aug 2004, seth vidal wrote:
syslog-ng supports regexs on logs, splitting on hostname, separate scripts per instance, tcp, alternate ports, stunnel wrapping of the whole daemon.
To be honest, I'd rather have good log parsing/reporting/watching tools that do all the work of maintaining regexs or what not for me, than a fancy syslog daemon.
regards,
On Mon, 30 Aug 2004, seth vidal wrote:
Look into epylog for that.
Aye, I did. But it doesnt 'know' about as much stuff as logwatch does.
But a syslog daemon that's not 25 yrs old would be a nice fresh start.
Possibly. But I'd rather have a bare minimum traditional syslogd rewrite than an all singing, all dancing rewrite whose bells and whistles i'll never use.
-sv
regards,
-
Iago Rubio -
Jose Pedro Oliveira -
Lennert Buytenhek -
nathan r. hruby -
Paul Jakma -
Russell Coker -
seth vidal -
Steve G -
Tom Diehl