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:hartmans-ietf@xxxxxxx] > Sent: Thursday, February 01, 2007 2:09 PM > To: Mark Andrews > Cc: IETF-Announce@xxxxxxx; syslog@xxxxxxxx; ietf@xxxxxxxx > Subject: [Syslog] Re: Last Call: draft-ietf-syslog-protocol (The > syslogProtocol) to Proposed Standard > > >>>>> "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. > > > _______________________________________________ > Syslog mailing list > Syslog@xxxxxxxxxxxxxx > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf