On Thu, Feb 01, 2007 at 08:09:29AM -0500, Sam Hartman wrote: > >>>>> "Mark" == Mark Andrews <Mark_Andrews@xxxxxxx> writes: > >> - 'The syslog Protocol ' <draft-ietf-syslog-protocol-19.txt> as > >> a Proposed Standard > > Mark> draft-ietf-syslog-protocol-19.txt recommends using a > Mark> reliable protocol. Existing implementations of syslog do > Mark> this and deadlock with nameservers which are logging via > Mark> syslog. > > > Please explain the deadlock in more detail. One of the primary > reasons for the syslog working group is reliable syslog, so I think we > need to focus on how to avoid the deadlock in other ways rather than > avoiding reliability. If you have 50,000 syslog lines to put out, and only enough network/disk/something bandwidth for 5,000 within the same time frame, that's a problem. If you insist on keeping all 50,000 lines of output, there is no solution to that problem. If you block, that's a big problem as it ultimatley totally disables the service attempting to log information. If you write to a growing backing store, well you'll run out of space eventually (even disk is not infinite). Compression can only get you so far. Ultimately you have to drop something, and if it's not the syslog output, it's the service's output. Reliability is the problem, and the advice we give our users is not to log reliably (or even to configure servers to log to a local file, circumventing syslog entirely). Note that reliable network transport of syslog information is equally damaging as reliable local storage of syslog output (eg by forcing disk synchronization of each line). At least one of today's syslog implementations insists that you prefix your filenames with a "-" if you /don't/ want it to fsync() every line. This default cripples DHCP servers. The current words in the draft; It may be desirable to use a transport with guaranteed delivery to mitigate congestion. May be adequate to the point of suggesting that reliable delivery might not be desirable. But on the whole the draft doesn't read that way, and it doesn't state the truth: reliable delivery of syslog output is always harmful. The point of bothering with reliable syslog delivery, if there is one, is for those very rare cases where losing the data is more harmful than harming system services. -- 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:
pgpql6q1UyfbN.pgp
Description: PGP signature
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf