On Thu, Feb 01, 2007 at 08:09:29AM -0500, Sam Hartman wrote:
"Mark" == Mark Andrews <Mark_Andrews(_at_)isc(_dot_)org> 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
pgptWvpzXiu29.pgp
Description: PGP signature
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf