Bugzilla – Bug 89
Logging broken again...
Last modified: 2005-09-28 14:39:49 CEST
1. TCP does not show queries received over TCP - it shows number of connections
established eg. someone connects to nsd daemon and does not send anything to it.
Connection times out and RTCP increases by 1 - RQ doesn't change.
2. Syslog entries are not sent by nsd's TCP daemons when they are currently
processing query (TCP session is in established state). In such situation syslog
entry is never sent to syslog.
1. Is there some documentation on what each counter is supposed to count? Or can
this only be found in the bind 8 source code?
2. It will eventually dump the statistics... after processing the _next_ tcp
connection. This is due to a race condition. When processing queries SIGILL is
blocked. Just before entering select(2) to wait for new requests the SIGILL
signal is unblocked. Because this operation is not atomic select is not
interrupted by the pending SIGILL. For this pselect(3) was invented.
Unfortunately on most systems it is implemented as a library call instead of a
system call so the race condition still exists. Getting rid of the race
condition is probably hard to do. But moving the unblocking of signals from just
before the select(2) to just before checking if nsd->mode == NSD_STATS will
greatly reduce the number of times the race condition occurs. But stats still
won't be dumped while the TCP connection is open.
In NSD 2.1.x we can fix this by only blocking the signal while processing the
query, not while reading/writing to the sockets. Some kind of race condition
between checking nsd->mode and going into select is still possible though. I'm
not sure if this can be fixed without pselect.
1. In bind 8.x source file bin/named/ns_stats.c you can find short description
of each stat entry.
2.It seems we definitely cannot have reliable logging on nsd 1.2.x and MAYBE we
can have it on nsd 2.1.x. Are there any plans for that ?
updated bugzilla status.
I've no details on the actual implementation status
If this still is an issue, please reopen the bug.
I'm now closing it.