Package: sysklogd Version: 1.5-5 When syslogd is configured to send messages to a remote target, and initial DNS lookup of the target host name fails, the lookup will be retried later.
The intention has clearly been to retry DNS lookups a limited number of times, and with some time between the attempts. However, the logic of this retry mechanism is flawed. There is effectively no delay between retry attempts. Also, under certain conditions, the number of retry attempts is effectively unlimited. These bugs have bad consequences for a system with broken DNS and remote logging enabled. For every logged message, syslogd will try a DNS lookup and wait until timeout. This slows syslogd down to a crawl. Once socket buffers start to fill up, the clients of syslogd also stall and the system becomes almost unusable. This bug applies to sysklogd 1.5-5 (lenny) as well as 1.4.1-18 (etch). Bugs: 1) syslogd.c, line 1797: Host name lookups are retried only when INET_SUSPEND_TIME has passed since "f->f_time". But once the suspend time has passed, if the first retry attempt fails, f_time is not reset. Therefore, the next log message will immediately cause a second retry, and so on. 2) syslogd.c: The number of retry attempts left is maintained in f->f_prevcount. However, this variable is also used to count the number of duplicate log messages. It is thus possible to keep increasing f_prevcount by sending duplicate messages at a sufficient rate. In this case, syslogd will continue to retry the DNS lookup indefinately. Proposed solution: * Reset the retry delay time after a retry attempt has failed. * Use separate variables for retry time and retry count instead of re-using variables that were created for a different purpose. Joris. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
