On Thu, Feb 01, 2007 at 10:30:17PM +0200, Pekka Savola wrote: > It's acceptable for the syslog sender to replace overflowing lines of > syslog (if some messages need to be dropped due to lack of resources) > with a message about rate-limiting, messages being dropped, or > whatever -- just the same way as messages might get dropped when > syslogging to a local media. Then the word that should be used here is not "reliable" without any exceptions tagged on. > As long as a) there is a message about syslogs getting dropped, and b) > this is infrequent in a well operated system (i.e. the system log > levels are set so that typically the amount of logging is OK), this > should be no problem. I should note that while this would be just fine, this is not in fact what presently deployed syslog implementations that implement "reliable" delivery (wether to network sockets or local files) do. Today they block. To use the world 'reliable' without illuminating clearly that exceptions must be made is dangerous. > IMHO, "reliable delivery of syslog output is always harmful" is very > much an over-statement. Well, I wasn't counting on shifting the definition of "reliable" to "somewhat reliable". Sure, "somewhat reliable delivery of syslog output is always harmful" is very much an over-statement, I'll agree with that. But I stand by what I said. > get even more syslog to send. While this is a serious problem when it > occurs, it should be easily solvable: just drop the messages (with a > suitable note in syslog or in the local log) that exceed the buffer > size or prune messages from the buffer using some more advanced > strategy. That would be fine. But again, this is not what current implementations do, and that is not "reliable" without exception. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins
Attachment:
pgpjHSUDXAyxM.pgp
Description: PGP signature
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf