RE: [Syslog] Re: Last Call: draft-ietf-syslog-protocol (The syslogProtocol) to Proposed Standard
Mark == Mark Andrews [EMAIL PROTECTED] 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 mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Syslog] Re: Last Call: draft-ietf-syslog-protocol (The syslogProtocol) to Proposed Standard
I am thinking on how to come this by on the protocol basis, but so far I have no good clue (except that Baszi is probably right and it is a purely operational issue). However, I know some problems in this relation and though it is not a deadlock issue, I would like to share the scenario for sake of completeness: It occurs on a typical *nix system that runs both syslogd and the dns daemon. So it could potentially occur on almost all *nix DNS servers. The problem exists if syslogd contains rules for remote forwarding AND these rules do contain hostnames which need to be resolved by DNS. A typical problem is that syslogd starts before the dns daemon. When it intend to send a message to the remote host, it must do a dns lookup, which fails because dns daemon is not yet active. The stock linux syslogd contains some logic which simply defers the connection request, but at the cost of some message loss. Other ways to avoid this problem is to use IP addresses in syslog configuration, host files or, as Baszi said, special configuration options for static address mapping in syslgod. I do not, however, know actual deadlock situations (that is neither syslogd nor dnsd can proceed because they are waiting on each other). I, too, would appreciate any details on that. Rainer -Original Message- From: Sam Hartman [mailto:[EMAIL PROTECTED] Sent: Thursday, February 01, 2007 2:09 PM To: Mark Andrews Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; ietf@ietf.org Subject: [Syslog] Re: Last Call: draft-ietf-syslog-protocol (The syslogProtocol) to Proposed Standard Mark == Mark Andrews [EMAIL PROTECTED] 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. ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
