RE: [Syslog] Re: Last Call: draft-ietf-syslog-protocol (The syslogProtocol) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> > >>>>> "Mark" == Mark Andrews <Mark_Andrews@xxxxxxx> writes:
> >
[snip]

> 	Similarly if syslogd is using a reliable transport
> 	to talk to another syslogd.  That too can block which
> 	will eventualy lead to blockages to applications /
> 	memory exhaustion.

*That* is a different beast, not yet discussed. I know that it exists
but it is not related to DNS. If it happens, it is really bad and
typically results in a complete system hang. There are some situations
where a lossy transport is preferable. For example, I have written a
syslog/TCP implementation which, if forced to run in single-threaded
mode, favours discarding messages over blocking as the later could
indeed lead to fatal problems on a typical linux system.

The root cause, however, is not reliable syslog per se. The root cause
is the implementation. A reliable syslogd actually needs to be
implemented with a non-blocking, de-coupled, buffered design. In almost
all cases, that means separate receiver threads, a to-be-processed
message queue and separate sender threads. Still, you have to decide
what to do if the queue size is exhausted. But that scenario is much
less likely. In that case, I'd still favour loosing some messages over
potentially loosing all AND the system the syslogd runs on. As far as I
see it, this is an app-layer issue out of scope for the underlying
protocol. The problem, of course, is that syslog is simplex and
hop-to-hop, so the original sender will never know that the message was
lost. Protocol-wise, I do not see any fix to that except integrating
some asynchronous notification mechanism. IMHO, this is outside the
scope of syslog.

It may be useful to add some hint to implementors pointing to this
blocking condition. But I am not sure if it is really justified.

Rainer

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]